Praktisch Domain Driven Design (DDD)

Dit boek wordt ook wel de ‘blue-book’ genoemd onder DDD ingewijden, oftewel de theorie achter DDD. Eigenlijk kocht ik het omdat ik dacht dat ik daarmee beter inzicht zou krijgen in domeinmodellering maar het ging om veel meer dan dat alleen…

DDD is een ontwikkelaanpak waarbij business en IT dichter bij elkaar worden gebracht. De kern van de software is – zoals bij veel applicaties het geval is – niet meer de database, maar het (core) domeinmodel. Developers zullen zich eerst moeten verdiepen in de business voordat er geprogrammeerd kan worden: dat is best wennen als je dit niet vaker hebt gedaan hebt. In DDD wordt de taal tussen developers en business ‘Ubiquitous Language’ genoemd. De laatste jaren heeft, door de komst van cloud toepassingen(microservices), DDD steeds meer aan populariteit gewonnen.

Hieronder zie je een willekeurig voorbeeld van een domeinmodel, met daarin 2 bounded contexts. Een bounded context is een belangrijk begrip in de DDD en daarmee wordt bedoeld dat een domeinconcept (zoals bijv. Customer hieronder) een eigen betekenis heeft in een bepaalde context.

Zo zijn er verschillende begrippen in DDD die eerst goed begrepen moeten worden voordat er goed mee gewerkt kan worden.

Uit ervaring kan ik vertellen dat strategic design één van de belangrijkste onderdelen van DDD is en ik zou er dan ook als eerste mee starten.
Onderdelen hiervan zijn:

• Bounded Context
• Continuous Integration
• Context map

Na de strategic design kan begonnen worden met tactical design. Onderdelen, of ook wel building blocks, zijn:

• Entity
• Value Object
• Aggregate
• Domain event
• Service
• Repository
• Factory

Details over deze concepten zijn terug te vinden in de blue-book of op internet (zie https://dzone.com/articles/ddd-part-ii-ddd-building-blocks).

Developers zijn snel geneigd om direct over te gaan op tactical building blocks in code omdat hiervan op internet de meeste voorbeelden hiervan te vinden zijn, maar houd er rekening mee dat er eerst een goed een domeinmodel moet liggen met een bounded context en aggregate (root)s.

Mijn ervaring is dat het juist modeleren van de aggregate roots en de relaties tot andere aggregate(root)s veel refactorwerk scheelt. Kortom: besteed hier voldoende tijd aan in de beginfase.

DDD in de praktijk

In mei 2018 is het Prinses Maxima Centrum (PMC) in Utrecht geopend. Het PMC centraliseert al het onderzoek naar kanker bij kinderen binnen Nederland. Deutsche Telekom Healthcare Solutions (DTHS) in Bunnik helpt het PMC het digitale ondersteuningsproces van moleculair onderzoek te implementeren. VX Company is door DTHS (een Trusted IT Partner van VX Company) gevraagd om mee te helpen aan de ontwikkeling van een nieuw te bouwen Moleculair Diagnostic Module (MDM). MDM is een losse web module dat gekoppeld is aan het Sympathy/Lifecare systeem van DTHS. Deze module ondersteunt het proces van de moleculaire analist.

Het MDM-project is gestart met DDD als ontwikkelaanpak vooral omdat DDD uitermate geschikt is bij nieuwbouw en complexere toepassingsgebieden. Bij de start van het project moest het moleculair diagnostische domein nog goed doorgrond worden. Gaandeweg is er meer kennis van het domein gekomen met hulp van de subject matter experts (SME) bij DTHS en het PMC.

Business modeling is de eerste activiteit geweest om een eerste concept domeinmodel te maken. Hiervoor is veelvuldig overlegd met de SME om een begrippenlijst te maken en het model uit te tekenen. Er is gebruik gemaakt van een whiteboard om interactief te modeleren en het eindresultaat is vastgelegd met de fotocamera. Microsoft Teams gebruiken wij als collaboratieplatform, hierin zit o.a. een teamchat maar ook een wiki. De resultaten van de modeleringssessies zijn elke keer als foto en tekst vastgelegd in de wiki. We gaan pragmatisch te werk, zonder ingewikkelde tooling maar met de simpelste oplossing waarin Agile werkt.
Onthoud dat het domeinmodel altijd in beweging is en blijft. In de Scrum sprints zijn regelmatig refactorslagen geweest om de code weer in lijn te brengen met vernieuwde inzichten van het domeinmodel en dat is een normaal proces binnen DDD.

Architectuur

DDD en architectuur zijn twee onafhankelijke onderdelen in het ontwikkelproces. Op DDD zijn verschillende architectuurstijlen mogelijk, bijv.: 3 layered architecture of onion/hexagonal architecture.

Wij hebben gekozen voor Clean Architecture van Robert C. Martin, aka Uncle Bob (https://www.amazon.nl/Clean-Architecture-Craftsmans-Software-Structure-ebook/dp/B075LRM681). Clean Architecture borduurt voort op de onion architecture waarbij vooral usecases (of ook wel interactors genoemd) een belangrijke rol spelen in combinatie met het core business model.

Dit is de Clean Architecture in grote lijnen:

De database is hierbij slechts een ‘detail’ zoals Uncle Bob aangeeft. Ook de web applicatie backend valt in de buitenring, waarbij de ringen alleen naar binnen mogen ‘kijken’ en niet naar buiten. In de kern zijn business entities met daarin de applicatie specifieke business rules. De ring daaromheen bevat use cases. De use cases maken instanties aan van entities en sturen ze aan, maar bevatten geen business logica (Uncle Bob noemt dit ook wel de ‘dans van de entities’).

Voor meer details met betrekking tot de Clean Architecture verwijs ik je graag naar het boek of internet (zie https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html)

Conclusie

Als ‘traditioneel’ opererende developer (database-focus) is het wennen om in de DDD stijl te werken. Het vergt een andere kijk op het implementeren van een stuk functionaliteit. Het is een unieke/eigen manier van werken die je je eerst goed eigen moet maken en daarvoor is een goede theoretische grondslag belangrijk maar vooral veel praktijkervaring. Pas DDD vooral toe op complexere toepassingen; voor simpele CRUD toepassingen die toch al dicht op de database-tabellen liggen, is DDD minder geschikt.

Als tip kan ik meegeven dat het implementeren van relaties tussen entities en value objects een punt van aandacht is: zorg dat je in de basis zo klein mogelijke aggregate roots hebt en relaties modelleert binnen je aggregate root waar nodig. Zie meer info in dit artikel: http://www.informit.com/articles/article.aspx?p=2020371&seqNum=3.

Wij hadden in het begin veel één op -n- relaties gemodelleerd en je merkt al gauw dat deze ook opgebouwd moeten worden vanuit een repository en dus veel performance kost. Beter is om de -n-kant van je relaties als losse operatie op de repository toe te passen zodat je deze vanuit een use case kunt ophalen.

DDD zorgt voor minder versnippering van business logica in code. Ook de strikte scheiding van data ophalen/wegschrijven en business logica maakt code onderhoud veel makkelijker, want het is op één plek te vinden. Unittests kunnen gemaakt worden om de business logica te testen zonder tussenkomst van een database. Ook de ‘taal’ van de SME is direct terug te vinden in code waardoor het veel natuurlijker aanvoelt. We hebben een hoge code coverage kunnen bereiken met DDD en in combinatie met de on-premise CI/CD straat in TFS en Sonar Server integratie, hebben we een triple A status op onze code.

Al met al ben ik zeer trots op datgene wat we bereikt hebben voor Deutsche Telekom Healthcare Solutions en het Prinses Maxima Centrum. Deze kennis kunnen we in de toekomst goed toepassen bij onze toekomstige klanten bij VX Company.