Domain-Driven Design

Veel New Nexus collega’s zijn gedetacheerd bij (middel)grote bedrijven met dito IT systemen. Om die complexe IT efficiënt te blijven realiseren heeft de Domain-Driven Design methode van Eric Evans veel waardevolle handvaten.

In oktober hebben 10 collega’s van New Nexus een 3-daagse cursus op ons kantoor in Tynaarlo gevolgd onder begeleiding van João Rosa, een Strategic Software Delivery Consultant van de Xebia Academy. De intensieve cursus bestond uit een tiental sheets en de rest was oefenen, oefenen en ook dag 3 weer oefenen (met eindelijk een beetje code;).

Volgens DDD heb je als realisatieteam veel kennis nodig van het business proces (domein) dat je gaat modelleren en uiteindelijk coderen, incl. de bijbehorende taal. Om dat domein te verkennen organiseer je een Event Storm. Dat is een sessie met alle domein experts (stakeholders) waarin je al samenwerkend kennis vergaart van het te informatiseren businessproces.

Tijdens de cursus werden zeven collega’s business owner van een departement die business events (bijv. cursus betaald, locatie besproken) vanuit hun rol (domein) op post-its moesten schrijven en in een volgorde ophangen. Vervolgens moesten ze het bijbehorende proces toelichten (tell the story). De overige drie collega’s, fungerend als realisatieteam, mochten daarover vragen stellen en verduidelijkingen direct noteren op post-its. Na een uur intensief het proces bespreken resulteerde dit in eerste flow van events.

Volgende stap in DDD is het modelleren van opgedane domeinkennis door het realisatieteam, bijv. een eerste logisch informatiemodel (zie foto). Door het visueel op een grote plaat te doen leverde dat veel discussies op en daarmee verduidelijking (ook wat we nog niet wisten).

Example Mapping

Tijd om weer de domeinexperts op te zoeken. Ondersteund door de Example Mapping methode werden specifieke voorbeelden besproken (en vastgelegd op post-its), zoals de vraag of je de cursus ook voor een groep kan betalen. De resulterende kennis werd toegepast om het domein model verder te ontwerpen.

Context Mapping

Daarbij met Context Mapping een verdeling gemaakt conform de business boundaries, waarin dezelfde betekenis geldt voor een concept, bijv. cursus bij marketing vs een cursus bij het trainings departement. Ook hier weer veel discussie, wat bijdraagt aan het gemeenschappelijk begrip van wat duidelijk is en wat niet.

Zo vonden nog een aantal iteraties plaats, waarbij elk realisatieteam (we waren in drie teams opgedeeld bij het modelleren) op een ander model uitkwam. Maar volgens DDD zijn er verschillende modellen om problemen op te lossen en zijn er geen goede en slechte. Het gaat om het verbeteren van je model en het leren van het domein.

In de laatste iteraties zul je ook de verschillende relatietypen tussen je domeinen (services) onderkennen, zoals customer/supplier, partnership, conformist, etc. Met elk hun specifieke eigenschappen. En de building blocks, waaronder de keuze voor Entities vs. Values.

Keep challenging the model (DDD in een notendop)

• Communiceren: Shared understanding (consistent taalgebruik in gesprek, document en code)
• Itereren: Het is een stuk goedkoper om snel over meerdere modellen te itereren en minder bruikbare prototypen weg te gooien voordat je begint met coderen.
• Focus op de kernprocessen (core domain) van de business. Overwegen om de ondersteunende domeinen in te kopen, uit te besteden of minder intensief te realiseren.

Multidisciplinair

Deelnemers aan de cursus: Hotze van der Meulen, Martijn Reemst, Rik Carton, Sander Kemperman, Stef Akkerman, Sybren Dijkstra, Remco Riswick, Richard Kroon, Erwin Hoeckx, Eric de Jong.