Introductie voor domain driven design - DDD

Jaren geleden voegde een getalenteerde softwareontwerper een bewerkingsfunctie toe die hij 'Divide and Conquer' noemde aan een populair opmaakprogramma voor kranten. Deze functie was goed ontworpen, maar niemand gebruikte hem. Dit is waarom:

1. De naam 'divide and conquer' had geen betekenis met betrekking tot de lay-out van kranten.
2. Niemand kon uitleggen wat de functie deed of waarom je hem zou gebruiken.
3. Niemand had om de functie gevraagd en niemand wilde hem.

Kortom, er werd meer gekeken naar wat er met het programma kon worden gedaan in plaats van waarom het moest worden gedaan. 

Maak kennis met domain-driven design (DDD): een benadering van softwareontwikkeling waarbij de nadruk ligt op het volledig begrijpen van het domein waarin de software zal worden gebruikt. Als je het domein begrijpt, loop je minder risico om functies toe te voegen die klanten helemaal niet nodig hebben of willen.

Wat is domain-driven design (DDD)?

Software is bedoeld om ons leven gemakkelijker te maken. Hiermee kun je processen in de echte wereld stroomlijnen en automatiseren of inspelen op gebieden die voor specifieke gebruikers van belang zijn. De zaken die software aanpakt zijn de domeinen waarvoor de software bedoeld is. Het domein van Digital Audio Workstation (DAW)-software is bijvoorbeeld de audio-industrie.  

Domain model uitleg

Softwareontwikkelaar Eric Evans zag hoe belangrijk het was om het softwaredomein te begrijpen. Om DDD te introduceren schreef hij het boek Domain-Driven Design: Tackling Complexity in the Heart of Software. In zijn boek zegt Evans: "De kern van software is het vermogen om domeingerelateerde problemen voor de gebruikers op te lossen. Alle andere functies, hoe belangrijk ze ook zijn, dienen dit basisdoel."

In het bovenstaande voorbeeld over de lay-out van een krant hoef je geen professionele vormgever te zijn om nuttige opmaaksoftware te maken. Maar je moet wel begrijpen hoe vormgevers hun werk doen als je software wilt maken die hun processen en procedures weerspiegelt. Alle functies bovenop wat zij nodig hebben, voegen weinig tot geen waarde toe.

Leidende principes van domain-driven design

In het kort gaat DDD over het ontwikkelen van software die systemen en processen in de echte wereld modelleert. De DDD-aanpak is gebaseerd op de volgende leidende principes:

• Concentreer je op het kerndomein: praat met mensen die in het domein werkzaam zijn voordat je begint met programmeren. Zij kunnen helpen bij het definiëren van processen, procedures en terminologie binnen dat domein. Als je bijvoorbeeld software ontwerpt om winkelvoorraad te beheren, ga dan in gesprek met de mensen die de winkelvoorraad beheren in plaats van mensen die bij HR of financiën werken.
• Verminder de complexiteit door ontwerpen op domain models te baseren: als je het domein begrijpt, maak dan een model dat dit domein weerspiegelt. Voorraadbeheersoftware moet bijvoorbeeld functies bevatten die belangrijk zijn voor vooraadbeheerders, zoals voorraadtrendanalyse, automatisch aanvullen, scannen van streepjescodes, enz. Het model is een diagram, grafiek of geschreven tekst die de organisatie en een abstractie van de kennis van de domeinexpert weergeeft.
• Spreek een gemeenschappelijke taal: in zijn boek heeft Evans het over het belang van een gemeenschappelijke taal. Iedereen die bij het project betrokken is, moet dezelfde taal gebruiken om over het domein te praten. Luister naar de woorden en zinnen die domeinexperts gebruiken. Gebruik dezelfde terminologie in het programma van eisen, het model en de code zelf.

Belangrijke termen voor DDD design

De volgende termen worden veel gebruikt binnen DDD:

• Domeinlogica: ook wel bedrijfslogica genoemd. Dit is het doel van je model en softwareontwerp. Het ontwerp is gebaseerd op de logica van bedrijfsregels in de echte wereld die worden vertaald naar programmeercode.
• Ontwerppatronen (DDD pattern): als er al code bestaat die een probleem oplost dat lijkt op het probleem waar jij aan werkt, pas die dan aan voor jouw gebruiksdoel. Zo hoef je niet steeds het wiel opnieuw uit te vinden.   
• Context: de omgeving die de betekenis van een woord, handeling of functie binnen het softwaredomein bepaalt. In een bepaalde context kan het bijvoorbeeld logischer zijn om een knop met 'Toepassen' te gebruiken in plaats van 'Opslaan'.
• Bounded context: voor grote projecten moeten meestal veel modellen worden geïntegreerd. Door de context af te bakenen, definieer je het logische kader waarin een model zich kan ontwikkelen. Dit helpt andere teams te begrijpen wat ze moeten doen om hun modellen bruikbaar te maken als ze aan andere modellen worden toegevoegd.
• Context mapping: een document, grafiek of diagram dat de relaties tussen meerdere bounded contexts weergeeft. Deze kaart laat de taal van elke context zien, de onafhankelijke implementatie en de interface die wordt gebruikt om te communiceren met andere bounded contexts.
• Entiteiten: een entiteit is een domeinobject dat wordt gedefinieerd door zijn unieke id in plaats van zijn attributen. Iemand koopt bijvoorbeeld een kaartje om een film te zien. Deze persoon is een entiteit omdat de unieke id bepaalt wie die persoon is, ongeacht veranderingen in haarkleur, gewicht, lengte, enzovoort. 
• Value object: een onveranderlijk object dat attributen heeft, maar geen duidelijke identiteit. Je koopt bijvoorbeeld een bioscoopkaartje zonder toegewezen zitplaats. Alle stoelen in de bioscoop zijn hetzelfde. De stoelen zitten vast en kunnen niet worden verplaatst, maar met je kaartje mag je elke stoel kiezen. In deze context is de stoel een value object.

Voordelen van domain-driven design

Het meest voor de hand liggende voordeel van DDD is dat iedereen dezelfde taal gebruikt. Als het ontwikkelingsteam dezelfde taal gebruikt als domeinexperts, leidt dit tot een softwareontwerp dat logisch is voor de eindgebruiker. Omdat de terminologie in de applicatie overeenkomt met werkzaamheden in de echte wereld, is er minder verwarring en zullen gebruikers sneller begrijpen hoe ze het product moeten gebruiken.

Andere voordelen zijn:

• De zakelijke kant en ontwikkeling zijn op elkaar afgestemd: omdat ze dezelfde taal gebruiken, kunnen ontwikkelaars beter met het zakelijke team communiceren. Dit verkleint het risico op misverstanden tussen het ontwikkelingsteam en de domeinexperts.
• Bescherming van domeinkennis: waardevolle kennis gaat niet verloren wanneer een team overstapt naar een andere project en wanneer er nieuwe mensen aantreden om een bestaand project te onderhouden.
• Meer flexibiliteit: de contextuele definities en afbakeningen maken het gemakkelijk om met veranderingen van eisen om te gaan, omdat iedereen hetzelfde begrip heeft van het bedrijfsdomein.
• Gemakkelijk te volgen: betere communicatie en gedeelde terminologie maken het gemakkelijker om de implementatie van eisen bij te houden.
• Beter gebalanceerde applicaties: Soms ligt er teveel nadruk op de UX/UI van software. Deze zijn belangrijk, maar het kan tot problemen leiden als bepaalde domeinvereisten worden verwaarloosd. Het maakt niet uit hoe leuk het programma eruit ziet als het niet doet wat gebruikers willen. Concentreer je op wat er nodig is binnen het domein en wat domeinexperts aanbevelen, zodat de software voldoet aan de behoeften en verwachtingen van de klant.
• Betere code: het volgen van DDD zorgt uiteindelijk voor nettere, betrouwbaardere code. Hiermee kun je ook herhaalbare best practices en ontwerppatronen vaststellen om toekomstige projecten soepeler en efficiënter te laten verlopen.

Nadelen van domain-driven design

Domain-driven design biedt veel voordelen, maar werkt niet per se voor iedereen in elke situatie. Enkele nadelen zijn:

• Vereist uitgebreide domeinkennis: er moet ten minste één domeinexpert in het team zitten. Deze expert moet alles weten over het domein waarin de software moet worden gebruikt. Zonder deze kennis zou je kunnen eindigen met functies die niet passen in de context van het domein.
• Werkt alleen voor complexe domeinen: voor relatief eenvoudige domeinen kan DDD een overbodige tijdrovende klus zijn. Voor de ontwikkeling van sollicitatiesoftware heb je bijvoorbeeld alleen wat eenvoudige formulieren nodig voor het invoeren van persoonlijke gegevens, werkervaring, referenties, contactpersonen voor noodgevallen enzovoort. Als je geen toegewijde domeinexpert nodig hebt, is DDD waarschijnlijk ook niet nodig.
• Mogelijk niet geschikt voor zeer technische projecten: de focus leggen op complexe bedrijfsdomeinen en bedrijfslogica werkt goed omdat je een gemeenschappelijke taal kunt ontwikkelen tussen ontwikkelaars en domeinexperts. Maar wanneer het project technisch complex is, is het moeilijk om een gemeenschappelijke taal tot stand te brengen die door mensen aan de bedrijfskant kan worden begrepen.
• Kan tijdrovend zijn: tenzij de ontwikkelaars al domeinexperts zijn, zullen ze veel tijd moeten doorbrengen met het bedrijfsteam om een grondig inzicht te krijgen in het domein. Maar dit kan uiteindelijk een voordeel opleveren wanneer alle domeinkennis eenmaal is vastgelegd. 

Als jouw organisatie software wil maken die goed aansluit op het beoogde bedrijfsdomein, kun je overwegen om domain-driven design te implementeren. Ook als DDD niet geschikt is voor jouw situatie, is het toch de moeite waard om er meer over te leren, omdat het kan helpen de communicatie tussen ontwikkelingsteams en domeinexperts te verbeteren. Betere communicatie leidt tot betere probleemoplossing en nuttigere software.