Wegwijs in AI-ondersteunde Domain-Driven Design: kansen, risico's en nieuwe manieren van werken

Gien Verschatse leidde een sessie over Domain-Driven Design en AI.

Domain-Driven Design gaat er al lang van uit dat diepe domeinkennis de basis is van kwalitatieve, onderhoudbare software.

Hoe dichter de bouwers van oplossingen bij het domein staan, hoe beter de software die ze maken.

De opkomst van AI-codeertools zoals Claude Code brengt een boeiende paradox met zich mee: AI verlaagt de inspanning om oplossingen te implementeren drastisch, maar dreigt tegelijk het leerproces kort te sluiten dat DDD in de eerste plaats waardevol maakt.

Wanneer developers AI gebruiken om domeintaal om te zetten in prompts — in plaats van de kennis zelf te verinnerlijken — wordt de fundamentele belofte van DDD stilletjes ondergraven.

Gien Verschatse, senior consultant bij Aardling, onderzoekt die centrale spanning: het verschil tussen AI gebruiken om sneller te gaan en AI gebruiken als vervanging voor het opbouwen van domeinexpertise.

Deze sessie verkent:

• AI-ondersteunde DDD-workflows

• Cross-functionele teamsamenstellingen, met AI in gedachten

• Hoe junior developers het risico lopen achter te blijven, en praktische remedies

Deze sessie is relevant voor software developers, team leads of technical leads die vandaag AI gebruiken in hun softwaresystemen.

Wat betekent "AI en domeinmodelleren in code" eigenlijk?

Een vraag die ik vaak zie op sociale media is: is programmeren nu een opgelost probleem dankzij AI? Ik denk het niet — en ik denk ook dat het afhangt van je definitie van zowel "programmeren" als "opgelost". Maar omdat we hier allemaal als Domain-Driven Design-practitioners zitten, vroeg ik me af of dat überhaupt de juiste vraag is. De code is maar het resultaat van een heel proces dat veel inspanning vraagt. Dus wilde ik me richten op hoe we AI echt kunnen gebruiken in elk van de drie fasen die we hebben: domain discovery, strategische DDD en tactische DDD.

Zonder twijfel is AI een heel nuttige tool. Er kan veel mee. Maar uiteindelijk blijft het een tool — het voorspelt het volgende token, het kan niet echt redeneren. Ik wil vertrekken van het DDD-principe dat de meeste practitioners al kennen: stop niet bij je eerste goede idee. Dat is een nuttiger kader dan vragen of programmeren opgelost is.

Ik gebruik doorheen de sessie een recyclagepark als voorbeelddomein, om de privacy van klanten te beschermen. In essentie: je komt binnen, scant je identiteitskaart, rijdt op de weegbrug, levert afval af en betaalt uiteindelijk. We hebben twee steden — Pointville en Oakland City — met verschillende prijsregels, en verschillende regels voor bedrijven versus particulieren. Alle scenario's die ik zal tonen, zijn gebaseerd op echte ervaringen met klanten.

Tactische DDD: wat AI out of the box fout doet

Toen ik AI de domeinkennis uitgeschreven in tekst gaf en vroeg om er een domeinmodel in code van te maken, merkte ik dat het dezelfde fouten maakt als ik toen ik begon te programmeren. Veel domeinkennis belandt in domain services — een van de tactische patronen waar je geen uitgebreid gedrag hoort te hebben. Je moet gedrag naar entities en value objects duwen, en domain services die alleen aan elkaar laten knopen. AI slaagt daar niet in, net zoals ik vroeger.

Het begrijpt ook het verschil niet tussen een entity en een value object, en welke situatie om welke vraagt. Het domeinmodel dat het produceert is niet schaalbaar — het bakt stadsspecifieke regels rechtstreeks in het model. Als je 100 steden hebt met 50 verschillende vrijstellingsregels, zit je met al die specifieke gevallen in je code, en dat willen we niet.

Het respecteert ook de domeintaal niet, en het weet dat het die niet respecteert. Het voert nieuwe woorden in terwijl de juiste termen er al zijn. Wij spreken meestal over "bezoekers"; het spreekt over "klanten". Het vertoont ook een heuristische bias: het begon te spreken over "drop-off line items", wat sterk lijkt op een bestelling, en importeert zo structuur uit e-commerce in een domein waar die niet thuishoort.

Tactische DDD: wat er gebeurt als je vooraf ontwerpt

Dat was zonder enig voorbereidend werk. Wanneer je vooraf wat ontwerpt — zelfs een ruw model op een whiteboard — verbeteren de resultaten aanzienlijk. In mijn voorbeeld schetste ik een prijsmodel met een duidelijke sleutelstructuur: stad, afvaltype en bezoekerstype. Ik scheidde de berekening van de standaard eenheidsprijs van de vrijstellingsregel. Wat ik van AI terugkreeg, lag veel dichter bij hoe we het zelf zouden geprogrammeerd hebben. Het maakte een fixed price calculator en een threshold calculator. Er was nog wat op te kuisen, maar de richting was juist.

Vooraf je domeinmodel ontwerpen wordt belangrijker, niet minder belangrijk, omdat je het gedetailleerde programmeerwerk niet meer zelf doet — de AI doet het voor je. Eén belangrijk verschil met werken met een junior developer: een junior neemt feedback mee over projecten heen en past die lessen elders toe. AI kan dat niet. Je begint altijd van nul.

De grootste winst is snelle iteratie. Je ontwerpt op een whiteboard, voert dat aan AI, krijgt een prototype, ziet wat niet werkt, past je model aan, voert het opnieuw in. Die iteratiecyclus was vroeger heel tijdrovend. Als je niet itereert, duw je een naïef eerste model naar productie — en dat hebben we nooit gewild.

Het grootste risico is dat het team het domeinmodel niet langer in handen heeft. Naarmate AI meer van het programmeerwerk doet, komt de kennis over hoe het systeem werkt niet meer in de hoofden van mensen terecht. Dat is een ernstig risico, want het maakt het heel moeilijk om het systeem in de toekomst aan te passen. We hebben ook nieuwe manieren nodig om geïmplementeerde domeinmodellen te valideren — we weten hoe we een model op een whiteboard valideren, maar het valideren zodra AI het geïmplementeerd heeft, zijn we nog aan het uitzoeken.

Domain discovery: de uitdagingen van werken met AI

We bleven horen dat teams diepe domeinkennis en een gedeeld begrip nodig hebben — en meestal bouwen we dat op via domain discovery en modelleren. Dus hoe kan AI daarbij helpen?

We botsten al vroeg op drie problemen. Het eerste was dat de kennis bevooroordeeld was. We gebruiken een aangepaste versie van Alberto Brandolini's EventStorming, en toen we AI probeerden te laten helpen bij domain discovery — aannames vinden, dubbelzinnigheid in taal, enzovoort — bleef het feedback geven op de techniek in plaats van op de inhoud. Verkeerde kleur post-it, ontbrekende policy-stickers. We moesten een legende bouwen en het precies uitleggen hoe wij EventStorming doen, voordat het zich op de inhoud kon richten.

Het tweede probleem waren de hiaten in de tooling. Ik liet Claude een event storm maken en kreeg er een SVG uit. Dan moest ik die in Miro krijgen. Miro heeft nu zijn eigen AI, en die kon de output omzetten, maar verloor daarbij de EventStorming-structuur: de tijd liep niet meer van links naar rechts. Een heel onhandige ervaring. We experimenteren nu met een domeinspecifieke taal als gedeeld formaat tussen AI-input en -output, om die kloof te dichten.

Het derde probleem was dat we geen waardevolle informatie kregen — alleen bevestiging van dingen die we al wisten. Wat hielp, was de input beperken. In plaats van AI de hele event storm te voeren, begonnen we het kleine fragmenten te geven en die van dichtbij te bevragen. De reden: hoeveel je het ook geeft, het volume van de output blijft ongeveer gelijk, dus het kan nergens diep op ingaan als de input te groot is. Kleine input, gerichte vragen, veel betere resultaten.

Domain discovery: AI echt nuttig maken

Zodra we met kleinere input begonnen te werken, kregen we er echt nuttige dingen uit. We vroegen het om aannames en open vragen te vinden. Voor het recyclagepark merkte het op dat we ervan uitgingen dat een bezoeker niet tegelijk particulier en bedrijfsklant kan zijn — er is geen mechanisme om daarmee om te gaan. Het vroeg ook hoe de jaarlijkse reset van de vrijstellingsregel precies werkt: is dat op 1 januari, of een lopend kalenderjaar vanaf het moment dat een bedrijfsklant zich inschrijft? Dat waren dingen waar we tijdens de modelleersessies niet aan gedacht hadden.

Een paar praktijken die helpen: wis de context regelmatig, want als je dat niet doet, begint AI eerdere delen van het gesprek erbij te halen en worden de antwoorden minder nuttig. En stel nooit suggestieve vragen — AI is ontworpen om het met je eens te zijn. Als je het vraagt om inconsistenties te vinden in iets, zal het die vinden, of ze er nu zijn of niet. Het is geen sparringpartner. Daarvoor heb je collega's nodig die echt kritisch kunnen denken. Maar het kan wel je rubber duck zijn: het helpt je snel itereren over ideeën en brengt dingen naar boven die je genoteerd had maar vergeten was terwijl je met ander werk bezig was.

Waar het echt goed in is, is inconsistenties in taal vinden. Het merkte op dat we "vrijstelling" op een niet-standaard manier gebruikten — in het gewone taalgebruik zou dat nul kost of uitsluiting impliceren, en zo werkt ons prijsmodel niet. Het kan ook meerdere woorden vinden die naar hetzelfde concept verwijzen: "afgeven", "afleveren" en "wegbrengen" beschrijven allemaal dezelfde handeling in het domein van het recyclagepark.

We zijn ook begonnen met transcripties in te schakelen in remote modelleersessies en delen daarvan achteraf aan AI te voeren: wat zie je hier? Hoe interpreteer je dit? Dat is echt nuttig gebleken om de volgende sessie voor te bereiden.

Een van de grootste risico's bij domain discovery is cognitieve schuld — een kloof tussen het team en hun begrip van het domein en de code, omdat ze de discovery en het programmeren niet meer zelf doen. Als die kloof te groot wordt, verlies je ook het vermogen om AI goede input te geven, waardoor je geen waardevolle output meer krijgt. Domeinexpertise wordt belangrijker, niet minder belangrijk.

Strategische DDD: grenzen, context maps en documentatie

Wat strategische DDD betreft kan AI helpen — maar ook hier maakt het beginnersfouten. Toen ik het vroeg om bounded contexts te ontwerpen voor het prijsberekeningsdomein, stelde het een aparte bounded context "prijslijst" voor. Maar een van de kernprincipes van grenzen ontwerpen is dat dingen die samen veranderen, samen horen. De prijslijst hoort binnen de bounded context voor prijsberekening te leven, niet erbuiten. AI dacht op het niveau van aggregates in plaats van op het niveau van bounded contexts — dezelfde fout die ik jaren geleden zou gemaakt hebben.

Voor context maps doet het sommige dingen fout — bijvoorbeeld de anti-corruption layer aan de upstream-kant plaatsen, terwijl die net bedoeld is om downstream te beschermen tegen upstream. Dat is een fundamentele fout.

Waar AI strategisch wel goed in is, is documentatie. Als je het vraagt om een bounded context canvas in te vullen zodra je een goede oplossing bereikt hebt, doet het dat accuraat. Het brengt zelfs aannames en open vragen naar boven die tijdens het ontwerpgesprek aan bod kwamen. Je kunt die documentatie in elk gewenst formaat krijgen — markdown, HTML, een afbeelding. En je kunt ze regelmatig bijwerken. Ik word meer een redacteur en validator van documentatie dan een schrijver ervan, en dat bespaart veel tijd.

Voor glossaria is het heel goed: geef het alle terminologie, vraag het om elke term uit te leggen met een voorbeeld, en het genereert snel een repository van gedeelde taal. Je kunt dat glossarium ook gebruiken om op inconsistenties te controleren.

Het algemene patroon voor strategische DDD: gebruik AI als inspiratie en voor documentatie, niet als ontwerptool. Het zal vaak natuurlijk ogende grenzen naar boven brengen die het overwegen waard zijn, maar het ontwerp zelf blijft jouw werk.

Belangrijkste inzichten

De snelheidswinst van AI zit vooral in drie gebieden: iteratie, experimenteren en documentatie. Je kunt snel itereren over domeinmodellen en prototypes. Omdat itereren goedkoper is, wordt experimenteren makkelijker — je kunt vragen "hoe zou dit eruitzien als we het concept particulier versus bedrijfsklant zouden schrappen?" en dat snel verkennen. Voor documentatie, vooral in strategische DDD, doet AI het meeste werk zodra je een goed ontwerp bereikt hebt.

Domeinexpertise is belangrijker geworden dan vroeger. Je hebt een diep begrip nodig, niet alleen om AI te sturen, maar ook om te valideren wat het produceert — iets wat je niet zelf gemaakt hebt. Het grootste risico in alle drie de fasen is cognitieve schuld: als het team het begrip van het domein niet langer in handen heeft, verliest het het vermogen om AI goede input te geven, en gaat het hele proces achteruit.

Domain-driven design blijft heel waardevol — het ging altijd al meer over je helpen denken dan over je helpen uitvoeren, en dat is precies wat nog steeds nodig is. Het denkwerk, het ontwerp van grenzen, de ubiquitous language, het domeinmodel — dat is allemaal nog steeds aan ons. AI is een goede tool, zeker gezien hoe algemeen inzetbaar het is. Leer hoe het werkt, leer hoe je er goed mee prompt, en neem het op in je gereedschapskist. Maar het ontwerp is mensenwerk.