Domain Driven Design in gewoon Nederlands (artikel 2): Het model

In het vorige artikel is DDD geïntroduceerd. Hierbij is beschreven wat de “why” is van DDD. Dit artikel zal dieper ingaan over het “wat” van DDD. Het “wat” van DDD is het middel om tot het doel te komen. Dit middel is het komen tot een “model”.

Wat is een “problem domain”?
De term “probleemdomein” wordt vaak aangeduid in DDD voor het definieren van een functioneel gebied in een organisatie. Een applicatie zal nimmer alle processen ondersteunen van de organisatie. Denk bijvoorbeeld aan applicaties voor personeelszaken en inkoop. Organisaties van enige omvang hebben hiervoor altijd verschillende applicaties. Personeelszaken is bijvoorbeeld een “probleemdomein”.

Er wordt een “model” opgesteld. Wat is een “model”?
Een groot denker en pionier op het terrein van Domain Driven Design, Eric Evans zegt over het “model” het volgende: “every model represents some aspect of reality or an idea of interest. A model is a simplification. It is an interpretation of reality that abstracts the aspects relevant to solving a problem at hand and ignores extraneous detail”

Een architect en/of analist faciliteert het opstellen van het model. Wat heb je dan? Het model beschrijft het “uiterlijk” en “gedrag” van het gekozen probleem domein. Het “uiterlijk” is de verzameling van gegevens die van belang zijn. Hierbij is ook de relatie tussen deze gegevens interessant. Het “gedrag” beschrijft de processtappen en gebeurtenissen die met/op deze gegevens plaatsvinden. Je kan het ook menselijk maken. Het gedrag is wat van buitenaf wordt gezien. Dit gedrag heeft intentie/motivatie, dat zijn de gegevens. Binnen DDD wordt gedrag beschreven als een verzameling van “events” en de intentie als een verzameling van “entiteiten”. De verzameling van deze beschrijvingen worden geborgd in tekeningen en code.

Wat is het doel van het model?
In artikel 1 wordt het “swingtree project” beschreven. Het middel om dit soort projecten te voorkomen is het model. Dit is de “why” van het modelleren. Het model levert documentatie in de taal van de kenniswerker in het probleemdomein. Dit betekent dat het model in een taal is geschreven zonder technische oplossingen en begrijpbaar voor de kenniswerker en andere betrokkenen. Concreet, er moeten termen worden gebruikt van de “werkvloer”. Als meerdere termen voor hetzelfde onderwerp worden gebruikt, moet de best passende term worden gekozen.
Het primaire doel van het model is dus het beschrijven van de “why” en “what” van het probleemdomein. Door middel van het model wordt:

• Kennis over het probleemdomein geborgd
• Spreken toekomstige gebuikers en de ontwikkelaars dezelfde taal
• De oplossing in code is herkenbaar, ook in de toekomst

Een secundaire doelstelling is het hebben van een basis voor het software ontwikkelteam om de oplossing te realiseren van het probleemdomein. Deze basis moet in de code worden herkend zodat ontwikkelaars snel vanuit het probleemdomein, de technische oplossing eigen kunnen maken. Op deze manier wordt code herkenbaar en wordt alleen noodzakelijke code geschreven. Binnen DDD wordt de taal van de werkvloer “ubiquitous language” genoemd.

Hoe pakken we dat aan?
Zonder het gestructureerd aanpakken van de analyse om tot het model te komen, kan een applicatie ontstaan zoals hieronder weergegeven. Voor een klein probleemdomein hoeft dat geen probleem te zijn. Echter, het probleem domein zal altijd onderhevig zijn aan veranderingen en wellicht uitbreidingen. Het resultaat is een nog complexer plaatje. Binnen DDD worden dergelijke oplossingen “Big ball of mud” genoemd.


Bron: Patterns, Principles and Practices of Domain Driven Design by: Millet & Tune

Beter is om deelgebieden van het probleemdomein te beschrijven. Dit zijn de “subdomains” van het probleemdomein. Per subdomein worden vervolgens de modellen opgesteld. Dit betekent ook dat de oplossing (de architectuur) bestaat uit subdomeinen. Het realiseren van de oplossing gebeurt met focus en kan zelfs door verschillende teams worden uitgevoerd. De applicatie resulteert dan in een plaatje wat vergelijkbaar is met de onderstaande.


Bron: Patterns, Principles and Practices of Domain Driven Design by: Millet & Tune

In het volgende artikel wordt dieper ingegaan op de inhoud van een model. Hier komen de termen als “aggregate root”, “entity” en “value objects” aan de orde.

Auteur: Arjen Kraak, Bergler Competence Center © 2018

Geinteresseerd in dit onderwerp? Lees dan ook het eerste artikel: www.bergler.nl/ddd-in-gewoon-nederlands-artikel-1-introductie (level-100)

Deel deze pagina via:
berglerDomain Driven Design in gewoon Nederlands (artikel 2): Het model