ВИ станува дел од разговорите за дизајн на системи, без разлика дали тимовите ја покануваат или не. Таа може да скицира API, да предложи шема за база на податоци, да генерира Dockerfile и да претвори нејасно барање за функционалност во листа на сервиси. Таа брзина е корисна. И токму затоа архитектурата има потреба од искусно расудување околу неа.

Дизајнот на систем не е дијаграм со доволно полиња. Тој е збир од одлуки за граници, начини на откажување, сопственост, конзистентност на податоците, оперативни трошоци и промени со текот на времето. ВИ може да го забрза првиот нацрт. Не може да преземе одговорност за последиците од лоша претпоставка.

Користете ВИ за да го проширите просторот на дизајнот

Најпродуктивната употреба на ВИ во архитектурата често не е да ја прашате за „најдобриот дизајн“. Побарајте од неа да создаде неколку веродостојни дизајни, а потоа разгледајте ги компромисите.

Замислете PHP заднински систем што мора да прифаќа нарачки од клиенти, да наплатува преку давател на платежни услуги, да резервира залиха и да известува зависни системи. Асистент со ВИ може да предложи синхрон тек на барања, дизајн управуван од настани или хибрид. Секој од нив може да биде разумен во зависност од барањата.

• Синхрониот тек е поедноставен за разбирање и може добро да функционира кога латентноста и зависностите се предвидливи.
• Асинхрониот работен тек може да изолира бавни или ненадежни интеграции, но воведува повторни обиди, дупликатна испорака и евентуална конзистентност.
• Хибридниот пристап може да ги задржи валидацијата и креирањето нарачки синхрони, додека објавува сигурна работа во заднина откако трансакцијата ќе се потврди.

Вредноста не е во генерираната архитектура. Вредноста е во побрзиот начин да се откријат прашања што во секој случај требало да бидат поставени: Што се случува ако наплатата успее, но резервирањето на залихата не успее? Може ли клиентот безбедно повторно да се обиде со барање што истекло поради временско ограничување? Кој систем ја поседува состојбата на нарачката? Колку брзо клиентот мора да го види резултатот?

ВИ е особено добра во предлагање алтернативи што тим под временски притисок инаку би ги прескокнал. Третирајте ги тие алтернативи како материјал за преглед, а не како авторитет за дизајнот.

Претворете ги нејасните барања во експлицитни договори

Најскапите архитектонски проблеми најчесто започнуваат како неискажани барања. „API-то треба да биде сигурно“ не е употребливо ограничување за дизајн. Сигурно при какви услови на откажување? За која операција? Со какво однесување видливо за корисникот?

ВИ може да помогне неформално барање да се претвори во конкретна контролна листа. За крајна точка за нарачки, тоа може да вклучува идемпотентност, правила за валидација, ограничувања на стапката, авторизација, барања за ревизија, семантика на одговорите и однесување при повторен обид. Техничкиот лидер потоа треба да ја потврди секоја ставка според вистинската потреба на производот.

Идемпотентноста е одлука за дизајн, а не имплементациски детал

Мрежните откажувања ги прават дупликатните барања нормални. Клиентот може повторно да го испрати истото барање затоа што не го примил првиот одговор. Ако создавањето нарачка создава и наплата, постапувањето со дупликати мора да биде намерно.

Вообичаен пристап е да се бара клуч за идемпотентност за операции со надворешни ефекти. Чувајте го клучот со отпечаток од барањето и завршениот одговор. Повтореното барање со истиот клуч може да го врати првичниот исход наместо да создаде друга нарачка.

POST /api/orders
Idempotency-Key: 5b4b7d0e-unique-client-key

{
  "items": [
    { "sku": "BOOK-001", "quantity": 1 }
  ]
}

Тешките прашања и понатаму се човечки: Колку долго треба да се чуваат клучевите? Што се случува кога истиот клуч повторно се користи со различна содржина? Дали барање во тек враќа конфликт, чека или открива ресурс за статус? ВИ може да наброи опции, но точниот одговор зависи од договорот за производот и оперативниот модел.

Одржувајте ги границите поедноставни од дијаграмот

Дизајните генерирани од ВИ често се движат кон многу сервиси затоа што имињата на сервисите прават дијаграмите да изгледаат организирано. Во практика, дистрибуираните системи ја заменуваат локалната едноставност со мрежни откажувања, координација на распоредувања, работа на набљудливост и проблеми со сопственоста на податоците.

За многу PHP апликации, модуларниот монолит е подобра почетна точка. Држете ги деловните области одвоени во кодот, наметнете јасни интерфејси и користете една апликација што се распоредува сè додека одредена граница не бара независно скалирање, ритам на издавање, безбедносна изолација или избор на технологија.

Корисен тест е дали предложениот сервис има јасен сопственик, сопствена одговорност за податоци и независно значајна оперативна причина да постои. „Има именка во доменскиот модел“ не е доволно.

ВИ може да помогне во идентификување на границите на модулите, но потврдете ги преку реални работни текови. Ако наплатата бара директни запишувања низ нарачки, цени, залиха и клиенти при секое барање, прераното раздвојување на тие компоненти може да создаде проблем со дистрибуирана трансакција без да донесе практична корист.

Дизајнирајте ја патеката на податоците пред интерфејсот

Привлечен API договор не е доволен ако основниот модел на податоци не може да ги одржи своите ветувања. Пред да прифатите генерирани предлози за шема, проверете ги кардиналноста, ограничувањата за единственост, индексите, потребите за задржување и границите на трансакциите.

На пример, табелата со нарачки не треба да се потпира само на апликацискиот код за да спречи дупликатни надворешни референци за наплата. Ако е потребна единственост, наметнете ја во базата на податоци. Ако залихата не смее да падне под нула, одлучете дали гаранцијата ја поседува трансакцијата во базата на податоци, условното ажурирање или друг механизам за конкурентност.

UPDATE inventory
SET available_quantity = available_quantity - :quantity
WHERE sku = :sku
  AND available_quantity >= :quantity;

Апликацијата мора да провери колку редови биле засегнати. Резултат нула може да значи недоволна залиха или SKU што недостасува, а API-то треба намерно да ги преслика тие случаи. Тука генерираниот код често изгледа точен, додека крие нецелосна патека за откажување.

Индексите на базата на податоци заслужуваат исто внимание. Предлог на ВИ да се индексира секоја колона што се пребарува може да ги зголеми трошокот за запишување и користењето простор. Почнете од набљудуваните шаблони на пристап: филтрирање, спојувања, сортирање и страничење. Потоа тестирајте репрезентативни пребарувања и разгледајте го добиениот план во околината на базата на податоци што навистина ја користите.

Направете ја асинхроната работа безбедна за повторување

Редиците се вредни за е-пошта, веб-куки, обработка на слики, извештаи и интеграциска работа. Тие не ја прават работата да исчезне; ја преместуваат во домен на сигурност што има потреба од сопствен дизајн.

Работникот може да се урне по извршување на надворешно дејство, но пред да ја потврди задачата. Затоа повеќето системи за редици вообичаено се третираат како системи што дозволуваат повторена испорака. Потрошувачите треба да бидат идемпотентни, повторните обиди треба да бидат ограничени, а неуспесите треба да бидат видливи.

• Користете стабилен идентификатор за настан или задача.
• Запишувајте обработени идентификатори таму каде што дупликатните ефекти би биле штетни.
• Разликувајте привремени неуспеси од трајни неуспеси при валидација.
• Користете одложувања за повторен обид што избегнуваат веднаш да ја преоптоварат нездравата зависност.
• Испраќајте ги исцрпените задачи на место каде што операторите можат да ги прегледаат и разрешат.

Ако апликацијата запишува во својата база на податоци и објавува порака, избегнувајте да претпоставувате дека тие две дејства се атомски координирани. Шемата outbox често е прагматичен одговор: запишете ја промената во доменот и запис за појдовен настан во една трансакција во базата на податоци, а потоа нека работник објавува неиспратени записи. Тој работник и понатаму мора да толерира дупликатно објавување, но системот повеќе не губи тивко настани меѓу две одделни дејства.

Побарајте од ВИ да го оспори дизајнот

Откако ќе подготвите решение, користете ВИ како структуриран критичар. Побарајте од неа да идентификува единствени точки на откажување, нејасна сопственост, проверки за авторизација што недостасуваат, небезбедни повторни обиди, ризици при миграција и оперативни слепи точки. Потоа прегледајте го нејзиниот излез со истиот скептицизам што би го примениле на коментар при преглед на код.

Добрите поттикнувачи вклучуваат реални ограничувања: очекувана форма на сообраќајот, прифатлива загуба на податоци, очекувања за опоравување, модел на распоредување, однесување на зависностите и способноста на тимот да управува со системот. Без тие ограничувања, генерираниот дизајн обично е дотерана шпекулација.

Најсилната архитектонска работа и понатаму се темели на јасни договори и умерени претпоставки. ВИ може да им помогне на тимовите побрзо да преминат од празна страница до корисни прашања. Не може да одлучи што никогаш не смее да откаже, каква сложеност е прифатлива или за каква идна промена вреди да се подготвите. Надвор од нацртот, тоа се одлуките што го прават системот сигурен.