Domain Driven Design Book Eric Evans

Oké, laten we het even hebben over Domain Driven Design (DDD). En dan specifiek over dat dikke boek van Eric Evans. Ja, dat ding dat eruit ziet alsof het direct uit een NASA-handboek komt. Klinkt eng? Mwah, eigenlijk valt het best mee. Denk er maar aan als een kookboek, maar dan voor software.

Serieus, want laten we eerlijk zijn, software development is vaak net zo chaotisch als een keuken tijdens het kerstdiner. Iedereen rent rond, er staat van alles op het vuur, en niemand weet precies wat de bedoeling is. En je eindigt vaak met iets dat eetbaar is, maar niet echt lekker. Of, in software termen, het werkt, maar niemand snapt hoe. DDD probeert dat dus te voorkomen.

Waar draait het om? Simpel gezegd: praten. Goed, effectief, en vooral: hetzelfde praten. Stel je voor: je wilt een taart bakken. De één noemt het "beslag", de ander "deeg", en weer een ander "smurrie". Dat wordt niks. Met DDD zorg je ervoor dat iedereen (programmeurs, experts, de koffiejuffrouw) hetzelfde bedoelt als ze "beslag" zeggen. Dat noemen we een Ubiquitous Language. Een fancy term, maar het komt erop neer dat je een woordenboek maakt dat iedereen begrijpt.

De Kern: Het Domein

Wat is dan dat "domein" waar DDD zo op hamert? Nou, dat is eigenlijk gewoon het probleem dat je probeert op te lossen. Stel, je bouwt een webshop voor bloemen. Dan is jouw domein: bloemen verkopen. Logisch toch? Maar dan komen de details. Wat voor bloemen? Hoe bezorgen we ze? Wat gebeurt er als een bloem dood aankomt? Al die vragen horen bij je domein. En die antwoorden... die zitten vaak in de hoofden van de experts.

En dit is waar het echt interessant wordt. Want wie zijn die experts? Niet altijd de mensen met de meeste diploma's aan de muur. Soms is het de bloemist om de hoek die al 30 jaar rozen verkoopt. Of de bezorger die precies weet hoe je een boeket onbeschadigd aflevert. Die mensen moet je aan je keukentafel (lees: meetings) hebben zitten. En je moet naar ze luisteren.

Bounded Contexts: De Tuinmuren van je Code

Oké, even terug naar die taart. Je hebt het beslag (of deeg, of smurrie, als je geen DDD gebruikt). Maar je hebt ook de oven nodig, de versiering, de doos om hem in te doen… Al die dingen zijn verbonden, maar wel apart. In DDD noem je dat Bounded Contexts. Zie het als kleine, afgebakende tuintjes binnen één grote tuin. Elke tuintje heeft zijn eigen regels en planten (lees: code en logica).

Waarom is dit belangrijk? Omdat je niet alles in één grote, onoverzichtelijke brei wilt stoppen. Stel je voor, de code voor het berekenen van de bezorgkosten zit vastgeplakt aan de code voor het weergeven van de productcatalogus. Dat wordt een puinhoop. Door Bounded Contexts te gebruiken, hou je je code netjes georganiseerd en makkelijker te begrijpen (en aan te passen!).

Entities en Value Objects: De Bouwstenen

Nu we de tuin hebben, moeten we natuurlijk ook wat plantjes planten. En dat zijn dan je Entities en Value Objects. Een Entity is iets dat een identiteit heeft. Denk aan een specifieke roos. Hij heeft een naam, een kleur, een prijs. Je kunt hem onderscheiden van andere rozen. Een Value Object is iets dat alleen wordt gedefinieerd door zijn waarden. Denk aan een kleurcode (bijvoorbeeld #FF0000 voor rood). Het maakt niet uit welke rode kleurcode je hebt, zolang hij maar rood is.

Dit klinkt misschien als mierenneuken, maar het helpt je om je code duidelijker te maken. Je weet precies wat de belangrijkste onderdelen zijn (Entities) en wat gewoon details zijn (Value Objects). En dat maakt het een stuk makkelijker om je code te onderhouden en uit te breiden.

Aggregates: De Baas in de Tuin

Oké, we hebben tuintjes, plantjes, en... wie houdt de boel nou in de gaten? Dat is de taak van de Aggregates. Een Aggregate is een groep van Entities en Value Objects die als één geheel worden behandeld. Denk aan een boeket bloemen. Het is meer dan alleen een stapel losse rozen. Het is een samengesteld object met zijn eigen regels en logica. Bijvoorbeeld: je kunt geen roos uit het boeket verwijderen zonder het hele boeket aan te passen.

Aggregates zijn belangrijk omdat ze de transactiegrenzen bepalen. Dat betekent dat alle wijzigingen aan een Aggregate in één keer moeten worden doorgevoerd. Anders krijg je inconsistencies. Stel je voor dat je een roos uit het boeket haalt, maar de prijs van het boeket niet wordt aangepast. Dat klopt niet. Aggregates zorgen ervoor dat alles coherent blijft.

Events: De Roep om Hulp

En dan hebben we nog Domain Events. Zie ze als de roep om hulp in je domein. Stel, een klant bestelt een boeket. Dat is een Domain Event. Of een bloem verwelkt. Ook een Domain Event. Domain Events zijn signalen dat er iets belangrijks is gebeurd. En andere delen van je systeem kunnen daarop reageren.

Waarom is dit handig? Omdat het je code loskoppelt. De code die de bestelling verwerkt, hoeft niet te weten wat er daarna gebeurt. Het enige wat het hoeft te doen, is een Domain Event afvuren. En andere delen van het systeem (bijvoorbeeld de code die de factuur genereert) kunnen daarop reageren. Dat maakt je code flexibeler en makkelijker te onderhouden.

Is DDD iets voor jou?

Oké, je hebt nu een crash course DDD gehad. Maar is het iets voor jou? Dat hangt ervan af. DDD is niet een zilveren kogel. Het is niet iets dat je zomaar even implementeert. Het kost tijd en moeite om te leren en toe te passen. En het is zeker niet geschikt voor elk project.

Als je een simpel CRUD-appje bouwt (Create, Read, Update, Delete), dan is DDD waarschijnlijk overkill. Maar als je een complex systeem bouwt met veel business logic, dan kan DDD je echt helpen om je code te organiseren en te vereenvoudigen. En om beter te communiceren met je domeinexperts.

En dat is eigenlijk waar het allemaal om draait. DDD gaat over communicatie. Over het begrijpen van het probleem dat je probeert op te lossen. En over het samenwerken met de mensen die het probleem het beste begrijpen. Dus pak dat dikke boek van Eric Evans (of begin met een samenvatting op internet), ga met je domeinexperts praten, en kijk of DDD iets voor jou kan betekenen. Wie weet bak je wel de lekkerste softwaretaart ooit!

En onthoud, net als bij koken, oefening baart kunst. Je zult in het begin vast wel eens iets verbranden, maar uiteindelijk krijg je de smaak te pakken. Succes!