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

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

Практичната цел не е „да се научи моделот на сè“. Таа е да се архитектурира софтверот така што важните одлуки се изразени во облици што и луѓето и системите со ВИ можат да ги најдат, толкуваат, тестираат и безбедно користат.

Деловната логика е повеќе од патеки во кодот

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

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

Ниту едно од тие барања не е очигледно од колона наречена status.

Направете ги одлуките разбирливи и локални

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

Корисен образец е на именувана доменска операција да ѝ се даде одговорност за деловна одлука. Наместо да им се дозволи на многу повикувачи директно да менуваат запис, обезбедете операција што ги прифаќа релевантните факти и враќа експлицитен резултат.

type CancellationDecision =
  | { allowed: true; accessEndsAt: Date }
  | { allowed: false; reason: "active_dispute" | "missing_permission" };

function decideCancellation(input: {
  hasPermission: boolean;
  hasActiveDispute: boolean;
  paidThrough: Date;
}): CancellationDecision {
  if (!input.hasPermission) {
    return { allowed: false, reason: "missing_permission" };
  }

  if (input.hasActiveDispute) {
    return { allowed: false, reason: "active_dispute" };
  }

  return { allowed: true, accessEndsAt: input.paidThrough };
}

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

Раздвојте ги политиката, оркестрацијата и несаканите ефекти

Развојот со помош на ВИ станува многу побезбеден кога системот разликува три аспекти:

• Политика: што е дозволено, задолжително или забрането.
• Оркестрација: подредениот работен тек што применува одлука.
• Несакани ефекти: запишувања во база на податоци, е-пораки, плаќања, пораки и повици кон надворешни API.

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

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

Претворете ги правилата во извршливи примери

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

Дајте предност на примери што опишуваат значајно сценарио, а не само детали од имплементацијата.

it("keeps access active until the paid-through date", () => {
  const decision = decideCancellation({
    hasPermission: true,
    hasActiveDispute: false,
    paidThrough: new Date("2030-06-30T00:00:00Z")
  });

  expect(decision).toEqual({
    allowed: true,
    accessEndsAt: new Date("2030-06-30T00:00:00Z")
  });
});

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

Дајте им на агентите алатки, а не широки овластувања

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

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

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

Изградете заедничка мапа на доменот

Имињата се дел од архитектурата. Ако една услуга нешто го нарекува „клиент“, друга „сметка“, а трета „организација“, и луѓето и ВИ ќе направат неточни поврзувања меѓу концептите. Воспоставете мал доменски речник и користете го во кодот, API, тестовите и документацијата.

Чувајте кратки објаснувања блиску до кодот за правила што лесно може да се разберат погрешно. Поврзете политика со нејзините тестови и со работниот тек што ја спроведува. Целта не е исцрпна документација; целта е да се намали бројот на места каде што некој мора да нагаѓа.

Направете ја ВИ учесник во добро дизајниран систем

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

Кога деловната логика е вградена на овој начин, ВИ станува покорисна бидејќи има подобри насоки што треба да ги следи. Развивачите ја добиваат истата придобивка. Архитектурата што му помага на моделот да го научи вашиот систем обично е архитектурата што му помага на вашиот тим да го менува без да ги изгуби причините поради кои бил изграден.