Domain-Driven Design

Begin 2020, nog voor het Coronavirus onze contreien bereikte, bracht ik een bezoek aan “Domain-Driven Design Europe”. Zoals zo mooi omschreven, een Software Modelling & Design Conference. Mijn interesse was namelijk gewekt in dit voor mij onbekende gebied waar termen als Ubiquitous Language, user story mapping, event storming, bounded contexts, context maps, … me uitdagend in de ogen keken.
Nu wat is Domain-Driven Design eigenlijk? Alvast kort een introductie van de kernbegrippen. 

DDD

Domain-Driven Design of verkort DDD kan omschreven worden als een software design approach. De naam is afkomstig van het gelijknamige boek geschreven door Eric Evans in 2004. En de aanpak omvat een reeks van patronen, principes en toepassingen om tot betere software ontwikkeling te komen. Zo probeert het structuur en code te verenigen via een gemeenschappelijke eenduidige taal en ontwikkeling te focussen op de kern van het domein.

The Ball of Mud!

Elke software ontwikkelaar kent het wel, heeft er misschien ergens mee gewerkt of alleszins van gehoord. Complexe code, werkende software waarvan lang vergeten is hoe deze nu werkelijk werkt. Meestal is die ooit geschreven met de beste bedoelingen en tegen een strakke deadline. Maar doorheen de jaren is de code uitgegroeid tot een complexe applicatie. Vergelijkbaar met een steeds groter wordende “ball of mud” of modderbal, waarin aanpassingen moeilijk zijn te verwezenlijken en tijd verloren gaat aan technische complexiteit. Daardoor kan er jammer genoeg minder gewerkt worden aan het feitelijk op te lossen probleem.

Nu hoe kan dit beter, duidelijker en liefst zelfs minder complex?

In DDD probeert men het model van het te behandelen domein te herleiden tot enkel dat wat nodig is om een probleemstelling op te lossen binnen de context van de applicatie. Alle vormen waarin dit model uitgewerkt wordt. Zoals code, diagrammen en documentatie gebruiken dezelfde “Ubiquitous Language” of eenduidige taal. 

Ubiquitous Language

In software ontwikkeling worden er wel al eens eilanden opgetrokken tussen de verschillende betrokkenen. Denk maar aan de business die met een probleemstelling zit en spreekt in vakjargon. Analisten die een vertaalslag maken en het technische team dat vooral op technische termen terugvalt. Zeker in code. Hierdoor ontwikkelt men onbewust elk een eigen taal.

Een “Ubiquitous Language” of gedeelde eenduidige taal moet daarom zorgen voor betere communicatie, een lagere kost in de vertaalslag van informatie tussen betrokken partijen en op die manier uiteindelijk ook een beter inzicht geven in het domein zelf. Net omdat iedereen dezelfde taal gebruikt.

Deze Ubiquitous Language dient dan ook consistent door alle betrokkenen gebruikt te worden tijdens het uitwerken van het domein. En zoals gezegd niet enkel in documentatie maar ook in diagrammen en code.

Knowledge Crunching

Ik sprak zonet ook al over dit model. Maar hoe kom je daar nu toe?
Knowledge Crunching is de manier om uit een probleemstelling relevante informatie te vergaren en zo tot een daarvoor bruikbaar model te komen. Dat komt uiteraard tot stand in samenwerking met alle betrokkenen. Om dit proces aangenamer en interactiever te maken kan je o.a. volgende methodes gebruiken:

• User Story Mapping
• Event Storming
• DDD Whirlpool

Belangrijk is dat het bekomen model niet bedoeld is om onveranderd te blijven en dus constant evolueert. Zo kunnen feedback en meerdere sessies met experten leiden tot de ontdekking van nieuwe belangrijke concepten. Inzicht geven in wat niet meer noodzakelijk is zodat focus op de kernzaken behouden blijft.

Bounded Contexts

Na verloop van tijd kan het toch gebeuren dat het model te complex en groot wordt. Minder expliciet en de afgesproken taal dubbelzinnig. Dat zal uiteindelijk weer evolueren tot de spreekwoordelijke “ball of mud”. Om net dat te vermijden is het noodzakelijk het model op te delen in “bounded contexts” of begrensde contexten. M.a.w. opdelen in meerdere op zichzelf staande kleinere modellen, expliciet per specifieke context met een eigen ubiquitous language.

Martin Fowler verduidelijkt dit ook mooi in volgend artikel: https://martinfowler.com/bliki/BoundedContext.html

Context map

Een context map of kaart is een eenvoudig (hand) getekend diagram dat bedoeld is om te verzekeren dat de grenzen tussen de verschillende (bounded) contexten expliciet vastgelegd zijn. Evenals de contactpunten ertussen. Belangrijk wanneer contexten door verschillende teams beheerd worden. De “kaart” moet eenvoudig genoeg zijn om zowel door domein als technische experten en andere betrokkenen begrepen te worden. Het bevat ook de onderdelen van het systeem die men nog niet goed begrijpt. Net ook om dat mee in beeld te brengen.

That’s all?

Ik hoop bij deze DDD iets wat een plaats gegeven te hebben. Of beter, minstens een lichte interesse aangewakkerd te hebben! In de komende weken doorloop ik met collega’s een corona-proof online DDD cursus, waarin er op al deze begrippen dieper en meer hands-on wordt ingegaan. Met als ultieme doel deze inzichten ook praktisch te kunnen benutten. Ik hoop dan ook hierop nog een aanvulling te kunnen brengen.