Når din AI-assistent ikke kan læse dine tanker

Lad os være ærlige: du har sandsynligvis irritret dig over AI-kodningsassistenter på et tidspunkt. Du beder om en funktion, og den spytter noget ud, der teknisk set virker, men som fuldstændig misser pointen. Generiske klassenavne. Logik spredt ud over hjælpeklasser. Ligegyldighed over for de forretningsregler, der gør din applikation speciel.

Her er den ubelejlige sandhed: AI'en er ikke problemet. Du er.

Ikke for at være anklagende – men for at være praktisk. AI-sprogmodeller er fantastiske til mønstergenkendelse og kodegenerering, men de er bundet af det, du giver dem. Giv en AI vag kontekst, og du får vag kode. Giv den uklare instruktioner, og du får uklar adfærd.

Det er her, Domain-Driven Design (DDD) kommer ind i billedet – og ærligt talt er det den bedste ting, der er sket for AI-assisteret udvikling siden autocomplete.

Hvad DDD faktisk er (uden den akademiske byrde)

Jeg ved, hvad du måske tænker: "DDD? Er det ikke den tungemetode med de 47 mønstre og den 800 sider tykke blå bog?"

Både ja og nej.

DDD er fundamentalt et væddemål om, hvor kompleksiteten bor i software. Premissen: i de fleste applikationer er den svære del ikke teknologien – det er at forstå og modellere domænet. Forretningsreglerne. Terminologien, der betyder noget specifikt her, men ikke der. Edge cases, der kun giver mening i en bestemt kontekst.

Så DDD siger: sæt en model af dit domæne i centrum af dit arbejde. Udtryk den model på et sprog, som både udviklere OG forretningsfolk forstår. Lad koden afspejle den model direkte.

Den strategiske del dækker det store billede: etablering af et delt ordforråd (kaldet Ubiquitous Language) og definition af grænser (Bounded Contexts), hvor det sprog forbliver konsistent.

Den taktiske del dækker byggestenene: entities med identitet, value objects defineret af deres attributter, aggregates der grupperer relaterede objekter, og domain events der fanger meningsfulde ændringer.

Anti-mønstret at holde øje med – og det her fanger selv erfarne udviklere – er "anemic models". Det er, når dine objekter bare er datamuffer med getters og setters, mens al den virkelige logik lever i separate serviceklasser. DDD skubber hårdt tilbage på dette: læg adfærden der, hvor dataen bor.

Hvorfor dette betyder noget for AI-kodningsassistenter

Her bliver det interessant for os i 2024 og fremover.

AI-sprogmodeller er i bund og grund mønstergenkendelsesmotorer på steroider. De forudsiger, hvordan kode skal se ud, baseret på, hvad de har set i deres træningsdata. Og her er problemet: træningsdataen er fyldt med anemiske CRUD-mønstre, generisk navngivning og spredt logik. Det er den nemmeste vej i de fleste kodebaser, så det er det, modellerne falder tilbage på.

Når du bruger DDD-principper, giver du fundamentalt set nogle guardrails, der styrer AI'en mod bedre resultater. Hvert DDD-artefakt, du opretter, bliver til prompt-materiale. Hver beslutning, du gør eksplicit, bliver til en begrænsning, AI'en kan arbejde indenfor.

Lad mig gennemgå de fire steder, hvor dette betyder mest:

1. Dit delte ordforråd bliver til AI'ens systemprompt

Forestil dig: du bygger et abonnementsstyringssystem. Dit team har aftalt, at "subscription," "plan" og "entitlement" betyder meget specifikke ting. Et subscription er en aktiv relation mellem en kunde og en plan. En plan definerer, hvad der er tilgængeligt. En entitlement er det, kunden faktisk får lov til at bruge.

Når du skriver en user story eller en funktionsbeskrivelse med disse præcise termer, kan AI'en internalisere det ordforråd. Bed den om at tilføje en funktion til "opgradering af subscriptions," og den vil generere kode, der respekterer disse distinktioner. Den vil ikke blande "plan" og "entitlement" sammen, fordi du har været eksplicit om deres separate roller.

Den ordliste, du vedligeholder til at onboarde nye udviklere? Den er også præcis det, AI'en har brug for. Samme information, dobbelt funktion.

2. Bounded Contexts holder AI-sessioner fokuseret

Har du prøvet at få en AI til at hjælpe med en funktion, der rører seks forskellige dele af dit system? Resultaterne er normalt rodede – halve ændringer, oversete afhængigheder, logik der modsiger sig selv på tværs af moduler.

Bounded contexts løser dette naturligt. Hver context er et defineret område, hvor en bestemt model og et bestemt sprog gælder. Når du arbejder i "Billing"-contexten, betyder "account" måske noget andet end i "User Management"-contexten. Det er fint, så længe grænserne er klare.

For AI-arbejdsgange mapper dette smukt over på fokuserede sessioner. "I dag arbejder vi i Order Fulfillment-contexten. Her er dens ordforråd og regler. Ignorer Inventory-contexten for nu." Sådan får du modellen til at holde fokus i stedet for at sprede sig ud over hele dit system.

3. Behavior-rich modeller beskytter dine forretningsregler

Det her er den praktiske sikkerhedsfordel, der ofte bliver overset.

Når du lægger forretningsregler inde i de objekter, der ejer de relevante data, er der ét sted at vogte dem. Når du spreder de regler ud over flere serviceklasser, kan ethvert stykke genereret kode komme til at omgå dem.

Tænk på en ordrevalideringsregel: en ordre kan ikke sendes, hvis betalingen ikke er clearet. Hvis den regel bor i Order.Ship(), er den beskyttet. Alt kode, der prøver at sende en ubetalt ordre, går gennem den check. Men hvis reglen bor i en separat ShippingService, kan en AI gladeligt generere en ny ShippingProcessor, der sender ordrer uden at tjekke betalingsstatus.

Behavior-rich modeller koncentrerer dine invariants på steder, hvor de faktisk kan beskytte systemet.

4. Tests bliver til eksekverbare specifikationer

DDD's fokus på invariants – regler der altid skal holde sande – oversættes direkte til testcases. "Et abonnement kan ikke fornyes, efter det er blevet annulleret." "En bruger kan ikke overføre flere kreditter, end de har tilgængeligt." "En ordre kan ikke sendes til en ufuldstændig adresse."

Disse er ikke bare gode tests. De er en definition af korrekthed, som en AI kan bruge. Skriv dem først, og AI'en har et konkret mål at kode imod. Den kan køre testene og vide med det samme, om den er på rette spor. Det er langt mere pålideligt end at håbe, den følger prose-beskrivelser af forretningsregler.

Fælder, du skal holde øje med

Jeg vil være ærlig over for dig: at bruge DDD med AI er ikke automatisk magi. Standardindstillingerne arbejder imod dig på nogle specifikke måder.

AI'en falder tilbage på anemisk CRUD. Hvis du beder om "en Customer-klasse," får du ofte et offentligt getter/setter-par med al logikken forvist til en separat service. Du er nødt til eksplicit at bede om adfærd på objektet, private setters og logik, der bor sammen med de data, den beskytter.

AI'en opfinder sit eget ordforråd. Du siger "order," den skriver "transaction." Du siger "subscription," den skriver "membership." Disse er ikke synonymer i dit domæne, men AI'en ved det ikke, medmindre du fortæller det. Konsistent, eksplicit ordforråd i dine prompts hjælper, men det hjælper også at lægge de termer i filnavne, klassenavne og kommentarer, hvor AI'en naturligt vil opsuge dem.

AI'en over-engineerer, når den er usikker. Når en AI ikke har klar vejledning om det rigtige kompleksitetsniveau, falder den ofte tilbage på elaborate mønstre – abstract factories, excessive interfaces, unødvendige lag. DDD giver faktisk en nyttig heuristik her: brug de dyre mønstre (aggregates, domain events, bounded contexts) kun, når domænekompleksiteten berettiger dem. For simplere domæner kan behavior-rich klasser med klare navne være alt, du har brug for.

Den praktiske konklusion

Her er min ærlige vurdering efter at have tænkt over dette mønster: DDD er ikke længere primært en kodningsmetodologi. Det er en kontekst-engineering-metodologi for AI-æraen.

Hver DDD-praksis, du adopterer, gør dit domæne mere eksplicit, og eksplicit er præcis det, sprogmodeller kan handle på. Det delte ordforråd, du bygger til dit team, bliver til det ordforråd, AI'en bruger. De bounded contexts, du trækker, bliver til naturlige arbejdsenheder for fokuserede AI-sessioner. De behavior-rich modeller, du opretter, bliver til beskyttede rum, hvor forretningsregler ikke stille kan omgås.

Du ville alligevel have lavet det arbejde, hvis du ville have vedligeholdelsesvenlig software. Nu giver det også udbytte med AI-assistenter.

De billige dele af DDD – sprogklarhed og adfærdskoncentration – gælder alle steder. De dyre dele – fulde taktiske mønstre, elaborate event sourcing – gælder kun, hvor domænekompleksiteten virkelig berettiger dem.

Start med de billige dele. Gør ordforrådet eksplicit. Læg adfærd sammen med data. Hold grænserne klare. Lad så AI'en hjælpe dig med at implementere resten.

Dit fremtidige jeg, der debugger kode kl. 2 om natten, vil takke dig. Og det samme vil den AI, der faktisk formår at hjælpe i stedet for at hindre.