Al een tijd geleden schreven we de door ons gevolgde workshop Domain Driven Design. Dat artikel wordt nog altijd veel gelezen omdat het een van de weinige Nederlandse artikelen is over dit onderwerp. Tijd dus om er eens een nieuw artikel over te schrijven!
Wat is Domain Driven Design ook alweer?
Het is een aanpak voor het ontwikkelen van applicaties bedacht door Eric Evans, hij schreef er ook een boek over: Domain Driven Design. De vertaling is eigenlijk Domein (het domein van het bedrijf, de core business) gedreven ontwerp voor applicaties.
Door het gebruik van Domain Driven Design (DDD) zorg je ervoor dat de manier waarop de code in elkaar zit hetzelfde is als hoe het bedrijf van de klant in elkaar zit. Je zorgt er eigenlijk voor dat de core business van het bedrijf, ook het middelpunt is van de code.
Begrijpen van het onderwerp (het domein)
De developers zullen eerst het onderwerp (het domein) moeten begrijpen. Ze moeten kennis hebben van bankieren wanneer ze een applicatie gaan bouwen om mee te bankieren. Dan begrijpen ze namelijk wat de moeilijkheden en uitdagingen zijn waar ze rekening mee moeten houden.
Daardoor krijg je ook steeds meer een gemeenschappelijke taal zodat alle betrokkenen bij het project elkaar kunnen begrijpen. Zo lopen de processen sneller en efficiënter. Bovendien hebben zo de betrokken partijen ook meer begrip voor elkaar waardoor er ook minder snel miscommunicaties ontstaan.
Modulaire code
Bij het gebruik van DDD zorg je er ook voor dat je code modulair is. Dan kun je makkelijk nieuwe features toevoegen of bugs oplossen. Dit past natuurlijk heel goed bij de Agile aanpak die we doorgaans hanteren.
Bij complexere applicaties zie je al snel dat de code niet meer te begrijpen is en alles door elkaar loopt en afhankelijkheden heeft. Bij DDD zorg je er van tevoren voor dat je een goed design maakt en door de code modulair op te bouwen, blijft het behapbaar.
Hoe ziet projectmanagement eruit bij Domain Driven Design?
Om je een beter beeld te geven van DDD geven we je een overzicht van de verschillende stappen die er tijdens een project worden genomen wanneer die uitgevoerd wordt op deze manier.
- Het domein (onderwerp) omzetten in een model
- Ontwerpen
- Ontwikkelen
- Testen
- Vervolgens ga je weer opnieuw aan de slag met stap 1 en blijf je deze stappen herhalen
Zo zorg je dat het hele project ook Agile aangepakt kan worden: het is mogelijk om later dingen gemakkelijk toe te voegen of besluiten toch niet te bouwen.
Voorbeelden lagen Domain Driven Design
Hieronder een diagram hoe de DDD lagen eruit kunnen zien. De bezoeker begint bij de interface en navigeert zo eigenlijk door de App en infrastructuur. Alle info die daarin gebruikt wordt komt eigenlijk uit het “Domain”.
De technische uitleg van de lagen:
- Interface: Dit is de ingang van de DDD lagen. Hier komen verschillende parameters binnen.
- App: Dit is de laag waarin het afhandelen van de applicatie logica gebeurt.
- Infrastructure: De app laag verwijst naar deze laag waarin bijvoorbeeld de database acties worden uitgevoerd in “repositories”
- Domain: Een “Domain” object kan bijvoorbeeld ook al gemaakt worden in de “Interface” laag. Het voordeel hiervan is dat je het object zelf doorgeeft aan de “App” laag en deze bijvoorbeeld aanvult met informatie. Vervolgens wordt het object zelf weer doorgegeven aan de andere lagen, zonder er dat er steeds heleboel aparte parameters gemaakt hoeven te worden.
Er kunnen meer lagen gemaakt worden wanneer die nodig zijn. Bijvoorbeeld een “Factories” laag waarin XML bestanden gemaakt kunnen worden.
Wat hebben wij inmiddels gedaan met DDD?
We hebben diverse projecten gedaan volgens deze aanpak. Het had vooral in het begin een aardige leercurve, maar inmiddels hebben onze developers het aardig onder de knie.
Voordeel van deze methodiek is dat we nu bij deze projecten meerdere lagen hebben opgebouwd in de code zodat je meer controle en overzicht hebt over de code. Daardoor kunnen we sneller features toevoegen en/of bugs oplossen. Zo kan de klant ook makkelijker zien wat er gedaan is aan het project.
We kunnen de code nu ook makkelijker automatisch testen, zodat niet alleen de snelheid omhoog gaat maar ook de kwaliteit.
DDD bij NN investment partners
Een van de klanten waarvoor de DDD hebben ingezet is voor N.N. investment partners. Bij hun applicaties is het ontzettend belangrijk dat dingen snel aangepast kunnen worden omdat hun business snel veranderd.
Door het gebruik van DDD kunnen wijzigingen snel geïmplementeerd worden en er komen minder bugs uit en ook de impact van wijzigingen zijn veel kleiner omdat het modulair opgebouwd is allemaal. Bij NN zijn ze er ook blij mee omdat het voor hen ook veel tijd en geld bespaard.
Heb jij ook een business die veel veranderd waar dus regelmatig (grote) wijzigingen doorgevoerd moeten worden? Dan is DDD misschien wat voor jullie!
