Domain-Driven Design

Wanneer ik met Domain-Driven Design (DDD) bezig ben, merk ik dat het zelden écht over code gaat. DDD is ontstaan rond het begin van de jaren 2000, in dezelfde periode als het Agile Manifesto en Extreme Programming. Niet toevallig: het kwam voort uit frustratie. Frustratie omdat we dachten dat we software konden ontwerpen door alles vooraf te analyseren en vast te leggen, om dan “gewoon” te bouwen.

In de praktijk werkt dat bijna nooit.

Een quote die voor mij de essentie van DDD samenvat is:

Die zin heeft mijn kijk op software bouwen fundamenteel veranderd.

Van plannen naar begrijpen

Ik heb vaak gezien hoe we in projecten starten met het idee dat we het probleem al begrijpen. Diagrammen, documentatie, backlog-items… alles lijkt duidelijk. Tot we beginnen te bouwen. Dan blijkt plots dat aannames fout waren, termen anders bedoeld zijn of processen complexer zijn dan gedacht.

Agile heeft me geleerd dat verandering normaal is. DDD leert me waarom die verandering nodig is: omdat ons begrip van het domein groeit terwijl we ermee bezig zijn. Software bouwen is leren. Punt.

Kennis ontstaat niet achter een scherm

Een van de belangrijkste inzichten die ik meeneem uit DDD is dat kennis niet vanzelf in code terechtkomt. Die kennis zit bij domain experts, en die haal je er niet uit met alleen tickets of documentatie.

Daarom geloof ik sterk in samen rond een whiteboard staan. Event storming, observaties delen, processen visualiseren, praten over “wat er écht gebeurt”. Dat sluit mooi aan bij de leerpiramide van Bales: we leren veel meer door te doen en samen te werken dan door te luisteren of te lezen.

Pas wanneer ontwikkelaars en domain experts dezelfde ruimte delen — letterlijk of figuurlijk — begint er echte kennisoverdracht te gebeuren.

Begrip is geen individuele keuze

Wat ik daarbij steeds vaker besef: developers zijn niet altijd in de positie om zelf te kiezen hoe sterk ze betrokken zijn bij de problem space of het leerproces. Die keuze ligt vaak bij leads, project managers of business analysts — expliciet of impliciet.

En precies daar ligt een belangrijke verantwoordelijkheid.

Hoe beter ontwikkelaars betrokken worden bij het begrijpen van het probleem, het stellen van vragen en het aftoetsen van aannames, hoe beter het eindresultaat wordt. Niet omdat developers “meer willen weten”, maar omdat software bouwen nu eenmaal een leerproces is.

Daarom is dit een expliciete oproep aan wie die rol opneemt:
faciliteer betrokkenheid. Nodig developers uit in gesprekken over het waarom, niet alleen het wat. Geef ruimte om vragen te stellen, aannames in vraag te stellen en mee te denken over het probleem, niet enkel over de oplossing.

Goede software ontstaat zelden door taken correct uit te voeren, maar door samen tot beter begrip te komen.

Taal maakt of breekt je model

Iets wat ik lange tijd onderschat heb, is hoe belangrijk taal is. We gebruiken woorden alsof ze vanzelfsprekend zijn, maar in de realiteit betekenen ze vaak iets anders afhankelijk van de context.

DDD maakt dat expliciet met het concept van ubiquitous language en bounded contexts. Binnen één context spreken we dezelfde taal, met dezelfde betekenis. In een andere context kunnen diezelfde woorden iets totaal anders betekenen — en dat is oké, zolang we die grenzen respecteren.

Sinds ik daar bewuster mee omga, merk ik dat misverstanden sneller verdwijnen en mijn modellen sterker worden.

Code volgt begrip

Voor mij is DDD in code geen doel op zich. Het is een gevolg. Wanneer het begrip van het domein groeit, volgt de code vanzelf: een rijk domeinmodel, duidelijke verantwoordelijkheden, hoge cohesie en lage coupling.

Goede code voelt dan niet meer als iets dat “afgedwongen” moet worden, maar als een natuurlijk resultaat van helder denken.

Tot slot

DDD heeft me vooral geleerd om trager te denken en sneller te leren. Niet meteen te optimaliseren, maar eerst te begrijpen. Niet te focussen op perfecte oplossingen, maar op betere vragen en op een goede manier kennis vergaren.