Wat is Domain Driven Design (DDD)?

Home / Blog / Softwareontwikkeling / Wat is Domain Driven Design (DDD)?

Domain Driven Design is een andere manier van het maken van software. Je zorgt ervoor dat je het probleem van een klant echt doorgrondt. Voor een klant zegt het weinig of alle code in één bestand gaat of dat de programmeur een monolithische structuur gebruikt. Programmeurs zijn vaak erg op de techniek gefocust, terwijl wij merken dat de klant juist meer behoefte heeft aan het meedenken bij een oplossing voor een probleem. De nieuwste techniek gebruiken lost niet zomaar het probleem van de klant op. Domain Driven Design helpt daar wel bij. Je stelt jezelf de vraag: ‘wat is het probleem van de klant en hoe kan ik dat zo simpel mogelijk oplossen?’ Daarbij is het belangrijk om naar ‘de vraag achter de vraag te vragen’. Vaak komen klanten al direct met specifieke wensen. Maar als consultant of engineer is het dan belangrijk goed te doorgronden waarom de klant dat wil. Daarvoor heb je mensen nodig die op het snijvlak zitten: die zich kunnen verplaatsen in het proces van de klant maar ook de technische mogelijkheden en gevolgen begrijpen.

Dezelfde taal spreken

Om DDD goed uit te voeren, is het belangrijk ‘dezelfde taal’ te spreken. Daarvoor wordt vaak een gemeenschappelijke woordenlijst aangelegd. De zogenaamde ubiquitous language, letterlijk vertaald ‘alomtegenwoordige taal’. Inleven in de klant is daarbij leidend: welke woorden gebruikt onze klant en hoe kunnen wij ons die eigen maken zodat we meegaan in zijn belevingswereld. Niet andersom. Als je met meerdere partijen in een applicatie werkt, kan dit nog extra lastig zijn. Omdat verschillende mensen hetzelfde woord gebruiken terwijl ze een ander concept in hun hoofd hebben. Onze engineer moet de juiste vertaling voor de computer maken zodat bij al die mensen gebeurt wat ze verwachten. Neem bijvoorbeeld het woord ‘orders’. Als het een webshop betreft, denkt de klant van de webshop aan zijn gemaakte bestellingen. De eigenaar van de webshop denkt aan zijn verdiensten, de magazijnmedewerker aan zijn te picken orders en de postpartner denkt aan zijn nog te versturen pakketten. De context bepaalt hier de betekenis. We mogen dus nooit zomaar een betekenis aannemen en moeten altijd doorvragen. Zulke definities nemen we op in de ubiquitous language lijst. Veel dingen benoemen klanten ook niet specifiek omdat die voor hen logisch zijn. Maar die moeten juist uitgesproken worden om zeker te zijn van alle stappen in een proces.

Event Storming

Een van de manieren om Domain Driven Design dan goed vorm te geven is Event Storming. Dat noemen we een modelleringstechniek. We kunnen beginnen met post-its en een lege muur. Iedereen mag meedoen door post-its te plakken met dingen die gebeuren in een proces, events dus. Daar komt de naam vandaan: i.p.v. een brainstorm doen we een eventstorm! 🙂 Dan kunnen we ze eventueel nog op volgorde hangen mocht dat niet direct zo zijn en dan ontstaat er een workflow. Omdat het daar visueel voor je staat, komen er ook sneller vragen. ‘Wat gebeurt er als die stap niet succesvol is?’ Deze eventstorm doen we samen met de mensen voor wie we de applicatie bouwen. Dat zorgt ervoor dat we direct antwoord krijgen op vragen.

Ook op zoek naar een oplossing voor uw businessprobleem? Senet helpt op gestructureerde wijze met Domain Driven Design en Event Storming. Neem vrijblijvend contact op met Geurt Jan van Ek.