DDD in gewoon Nederlands Artikel 1: Introductie (Level 100)

Als Lead Developer ben ik betrokken bij het opmaken van business cases, uitwerken van ideeën en het implementeren van softwareoplossingen. Een steeds vaker terugkomend thema is dat mijn relaties hun applicatie landschap willen moderniseren zonder opnieuw het wiel te willen uitvinden. Met andere woorden, men wil voortbouwen op het goede wat er al is. Meestal is het geen goed idee om de optie “opnieuw beginnen” ter tafel te brengen. Maar hoe kunnen we onze klanten dan wel op weg helpen?

Het opnieuw beginnen is dus geen optie. Werken met een “brown field” is dus het beginpunt. De aanpak waarmee ik start is het in kaart brengen van het probleemgebied. Hierbij wordt het bestaansrecht van de applicatie (het waarom en wat) onderzocht. Via dit model wordt vervolgens onderzocht hoe de applicatie opgeknipt kan worden op basis van thema’s in dit model. Dit ontvlechten van de applicatie wordt in software termen vaak het “ontvlechten van de monoliet” genoemd.

Middels deze blog serie, deel ik graag een methodiek uit 2003 die tegenwoordig heel actueel en toepasbaar blijkt te zijn. Deze methodiek is Domain Driven Design. Helaas is het zo dat bij het beschrijven van deze methodiek (te) snel de route van abstractie en technologische gevolgen wordt bewandeld. Ik pak dat deze keer anders aan.

Zodra je googled op “DDD” krijg je een spervuur van termen, toepassingen en dergelijke tot je beschikking. Hieronder een woordwolk van veel gebruikte termen.

Verschillende termen uit deze woordwolk zullen aandacht krijgen in dit en erop volgende artikel(en). Laten we beginnen bij het begin.

Software ontwikkelen is een complexe inspanning die vaak leidt tot onbegrip. Dit onbegrip komt vooral voort uit het vertalen van de wens (het idee) naar de oplossing. Met alle goede bedoelingen en processen (“Scrum”, “Agile” !), blijkt jammer genoeg in de praktijk dat het resultaat lijkt op het beroemde “Swingtree project”.

Het “Swingtree project” is een metafoor die regelmatig wordt getoond om aan te geven dat er wezenlijke verschillen bestaan in begrip:

  • Wat de gebruiker / klant heeft gedeeld over de wens
  • Wat de gebruiker / klant werkelijk nodig heeft
  • Hoe de architect de wens heeft vertaald naar het ontwerp
  • Hoe de ontwikkelaar het ontwerp heeft geïmplementeerd

Uiteindelijk blijft het ontwikkelen van software mensenwerk. Mensenwerk vereist veel investeren in communicatie en afstemming. Vooral in de fase van een project waar nog geen regel code is geschreven moet er veel worden gecommuniceerd en gedocumenteerd om zoveel mogelijk te voorkomen dat uiteindelijk een product wordt opgeleverd wat lijkt op de schommel. De methodiek Domain Driven Design is zeer bruikbaar zowel in de verkennende fase van een project, als in de realisatie.

Onderaan de streep is het de bedoeling dat door middel van een gemeenschappelijke taal (“Ubiquitous language”) een ontwerp (“Domain Model”) ontstaat waarin middels afbakening van thema’s (“Bounded Context”) de onderwerpen (“Entities”) worden beschreven. Kernwaarde hierbij is dat dit wordt gedaan zonder verwijzing naar de oplossing zelf (technologie en software architectuur). Domain Driven Design gaat dus over de wens / probleem en niet over de oplossing.

In de volgende artikelen zullen we wat dieper ingaan op enkele onderwerpen uit de Domain Driven Design methodiek. Hiervoor zitten de volgende artikelen in de pen:
• DDD-2: Het model
• DDD-3: Entity, value en aggregate (The Good, The Bad and the Ugly)
• DDD-4: Voorbeeld case studie

Auteur: Arjen Kraak, Bergler Competence Center © 2018

Geinteresseerd in dit onderwerp? Bezoek dan ook ons (gratis) Developers-event op 19 juni: https://www.bergler.nl/event/domain-driven-design-en-microservices-in-de-praktijk/

Deel deze pagina via:
berglerDDD in gewoon Nederlands Artikel 1: Introductie (Level 100)