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

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

Поттикнувањата ја опишуваат намерата; софтверот ја спроведува

Едно поттикнување може да каже: „Никогаш не нуди попуст поголем од 15%, и само за подобни клиенти.“ Тоа звучи јасно сè додека клиент не побара исклучок, моделот погрешно не го прочита контекстот на сметката или подоцнежна измена на поттикнувањето не ја промени формулацијата. Деловното правило сега е расфрлано низ природен јазик и тешко е да се тестира со сигурност.

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

final class DiscountPolicy
{
    public function maximumFor(Customer $customer): int
    {
        if (! $customer->isEligibleForDiscount()) {
            return 0;
        }

        return $customer->isPremium() ? 15 : 5;
    }

    public function allows(Customer $customer, int $percentage): bool
    {
        return $percentage >= 0
            && $percentage <= $this->maximumFor($customer);
    }
}

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

Дајте му на моделот способности, а не пристап до базата на податоци

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

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

Секоја способност треба да има здодевно експлицитен договор:

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

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

Чувајте ја вистината во базата на податоци, а правилата во доменот

Јазичните модели се добри во работа со двосмислен текст. Тие не се замена за трансакциска состојба. Тековното салдо, достапните залихи, статусот на претплатата и историјата на одобрувања припаѓаат во системи дизајнирани да ја зачуваат вистината при истовремени промени.

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

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

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

Направете ги неуспесите дел од дизајнот на производот

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

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

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

Користете поттикнувања за насока, не за управување

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

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

Практичниот тест е едноставен: ако поттикнувањето биде отстрането или погрешно разбрано, дали системот сè уште би ги заштитил клиентот и бизнисот? Ако одговорот е не, правилото припаѓа под поттикнувањето.

Сигурниот систем со ВИ е претежно сигурно инженерство

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

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