Wat is Domain-Driven Design en wat kan het jouw organisatie bieden?
Laten we voorop stellen: Domain-Driven Design (DDD) is actueel en relevant, maar niet nieuw. Het concept werd al in 2003 geïntroduceerd door Eric Evans. In zijn gelijknamige boek reageert hij op de uitdagingen die ontwikkelaars tegenkomen bij de bouw van complexe systemen. Developers merkten dat bestaande benaderingen niet meer toereikend waren om domeinspecifieke problemen aan te pakken.
In de loop der tijd zijn softwaresystemen alleen maar complexer geworden, met steeds meer afhankelijkheden. Gelukkig staan technologische ontwikkelingen ook niet stil en brengen die de implementatie van DDD voor steeds meer organisaties onder handbereik.
Wat is DDD eigenlijk? Wat zijn de voordelen ervan en hoe verhoudt het zich tot het nieuwe platform OutSystems Developer Cloud (ODC)?
Wat is Domain-Driven Design?
Hoe Domain-Driven Design werkt, laat zich het beste uitleggen aan de hand van een voorbeeld: een boek dat verkocht wordt in een fysieke winkel en een boek dat via een magazijn wordt gedistribueerd. Deze twee domeinen – de zogeheten “bounded context” – hebben elk andere informatie nodig over hetzelfde boek. De winkelverkoper wil naast het ISBN, ook de titel, de auteur, het genre en de verkoopprijs weten. De logistiek medewerker in het magazijn wil ook het ISBN weten, maar hoeft niet te weten wie de auteur is of tot welk literaire genre het behoort. Wel zijn de afmetingen van het boek en het gewicht belangrijk zodat hij weet hoeveel exemplaren er kunnen worden opgeslagen en vervoerd. Daarnaast is de magazijnlocatie voor hem belangrijk.
Je ziet dat deze twee domeinen heel andere informatie nodig hebben over hetzelfde boek voor hun dagelijkse bedrijfsvoering. Wanneer de verkoopprijs van een boek verandert, dan is het belangrijk dat de winkelverkoper dit zo snel mogelijk weet. De magazijnmedewerker hoeft dit niet te weten, hij verkoopt immers geen boeken maar opslagruimte. En de winkelmedewerker hoeft niet te weten dat het boek in het magazijn naar een ander schap is verplaatst, terwijl het logistiek proces in het magazijn natuurlijk in het honderd zou lopen als deze informatie daar ontbreekt.
Binnen DDD wordt de software op zo’n manier ingericht dat het aansluit bij wat binnen de bounded context belangrijk is. Wanneer deze domeinen iets van elkaar nodig hebben, bijvoorbeeld als de winkel een boek verkocht heeft, genereert dit een “event” dat voor het magazijn relevant is. Dit event triggert een proces in het distributiedomein waarbij een verzendorder wordt aangemaakt en de voorraad wordt bijgewerkt. De twee domeinen gebruiken een vooraf gedefinieerde taal, de “ubiquitous language”, en via een “event broker” communiceren ze met elkaar om misverstanden te voorkomen.
Wat zijn de voordelen van Domain-Driven Design?
DDD kent een aantal verbeteringen ten opzichte van traditionele softwareontwikkeling met een monolithische architectuur. Binnen DDD wordt het monoliet opgehakt in kleine
domeinen en dit maakt de softwareomgeving beter te overzien en te onderhouden. Onderlinge afhankelijkheden verdwijnen waardoor domeinen vrij zijn binnen hun eigen context software te ontwikkelen en op hun eigen tempo te releasen. Dit maakt het makkelijker nieuwe functies uit te rollen en bugs te verhelpen. Deze onafhankelijkheid zorgt er ook voor dat er makkelijker opgeschaald kan worden.
Kortom: meer flexibiliteit, minder afhankelijkheden, beter onderhoudbare systemen en sneller te realiseren business-waarde.
Randvoorwaarden voor Domain-Driven Design
De overstap naar DDD kan grote voordelen opleveren en je softwareomgeving positief transformeren, mits er aan een aantal randvoorwaarden wordt voldaan.
- Bounded context: definieer de domeinen. Dat doe je door een natuurlijke opdeling binnen de business te maken. Wat zijn de verantwoordelijkheden van de verschillende rollen hierbinnen?
- Ubiquitous language: definieer een gemeenschappelijke taal die zowel door ontwikkelaars als experts binnen het domein wordt begrepen. Deze taal gebruik je in alle communicatie binnen het domein en met de event broker. Dat programma zorgt ervoor dat de betreffende domeinen de informatie krijgen die zij nodig hebben voor een bepaald event.
- Samenwerking: het is belangrijk dat iedereen volledig op de hoogte is van wat er speelt binnen het domein. Business en developers moeten op dagelijkse basis contact hebben en samenwerken.
- Modelleren: de structuur van de code weerspiegelt één-op-één de structuur van het domein. Alle betrokkenen begrijpen die structuur. Daar waar wijzigingen in het domein tot stand komen, moeten in de code óók wijzigingen plaatsvinden.
- Werk incrementeel: begin met voldoende architectuur om het meest urgente probleem op te lossen. De code evolueert terwijl je meer leert over het probleem en meer architectuur toevoegt. Stapje voor stapje.
ODC en DDD
Overstappen op DDD biedt waardevolle kansen voor je organisatie. Het vraagt echter wel om een nieuwe manier van werken. Was het voorheen een hele kluif om dit te implementeren, tegenwoordig zijn er steeds meer oplossingen en automatiseringstools beschikbaar om in ieder geval het technologische aspect laagdrempeliger te maken. Moest je in OutSystems 11 nog zelf een event broker applicatie bouwen, ODC heeft dit al standaard in zich. ODC maakt de stap naar DDD dus makkelijker, ook omdat met een Domain-Driven aanpak de voordelen van ODC beter naar voren komen. Het versterkt elkaar.
Hoe ingrijpend de stap naar DDD is, hangt onder andere af van de maturity van je IT-landschap en organisatie. Met een grote monoliet en voornamelijk OutSystems Traditional Web-apps is er meer werk aan de winkel, maar ook hierbij is DDD niet onhaalbaar. Een ODC assessment kan allerlei nuttige inzichten bieden, bijvoorbeeld in hoeverre je applicatielandschap een weerspiegeling is van de organisatie.
Wil je meer weten over Domain-Driven Design en wat het voor jouw organisatie kan betekenen? Klik hier voor onze contactpagina!
Edwin Muijen, Principal Consultant, CoolProfs