Complexiteit aanpakken met Domain-Driven Design

Complexe modellen

Een van de ultieme uitdagingen voor een architect is het grondig begrijpen van de core business van het bedrijf waar hij oplossingen voor realiseert en dit begrip om te zetten in een model dat begrepen wordt door iedereen binnen het bedrijf, van eindgebruikers tot collega architecten.

In de praktijk zie je dat systemen vaak ontworpen worden op basis van use case specificaties. Use cases beschrijven individuele gebruiksscenario’s van een systeem zonder de context van de onderneming in oogschouw te nemen. Door bij het ontwerpproces alleen gebruik te maken van use case specificaties groeit de systeemcomplexiteit: op basis van deze specificaties ontstaan er grote hoeveelheden losstaande, technische componenten die op één of andere manier met elkaar samenhangen. De verbinding met het mentale model van de gebruiker raken we onderweg in grote mate kwijt en de middelen (het creëren van het systeem door use cases te volgen) worden het doel.

Het gebruik van use cases om een systeem te modelleren is te vergelijken met het creëren van een plattegrond van een stad door middel van een lijst van duizenden routebeschrijvingen tussen verschillende adressen. Geen enkele lezer zal in staat zijn om een mentaal model te vormen van wat hij ziet en het grotere geheel herkennen. Wanneer je de lezer een plattegrond geeft, zal hij snel begrijpen hoe de stad eruit ziet en eenvoudig zijn weg erin kunnen vinden. Sterker nog, de lezer is snel in staat om verbeteringen te suggereren waardoor mensen sneller van A naar B kunnen komen.

Naast de use case specificaties worden er ook andere technieken en tools gebruikt bij het beschrijven van een systeem, zoals verschillende UML diagrammen, Archimate, Zachman, TOGAF en DYA. Deze modellen richten zich steeds op één specifiek aspect en zijn voornamelijk bedoeld voor intern gebruik door architecten en bij het ontwikkel- en onderhoudsproces. Ze kunnen niet gevalideerd worden door mensen buiten dit proces. Ofwel, wat voor zin heeft het maken van een model als er een hele IT opleiding voor nodig is om deze te kunnen lezen, laat staan te valideren. We hebben iets nodig wat beter op het mentale model van een gebruiker past en systemen tegelijkertijd niet onnodig complex maakt.

Domain-Driven Design

Eric Evans heeft een paar jaar geleden een boek geschreven met de naam: “Domain-Driven Design: Tackling Complexity in the Heart of Software” [1]. De belangrijkste pijler in deze aanpak is dat hij zich richt op het gebruik van een gemeenschappelijke taal (ubiquitous language). Deze taal wordt door alle betrokkenen gebruikt; eindgebruikers en ontwikkelaars gebruiken dus dezelfde taal wanneer zij over het systeem praten. Dit helpt enorm bij het verkrijgen van een gemeenschappelijk beeld van het systeem door alle betrokkenen. Het model van het systeem dat zij op deze wijze maken, komt overeen met de echte wereld. Bijvoorbeeld, een entity java object genaamd “UitgeleendBoek” is een daadwerkelijk uitgeleend boek in een echte bibliotheek. De methode gaat dus zelfs zover dat ook tijdens de implementatie van het systeem gebruik gemaakt moet worden van dezelfde taal. Zo wordt voorkomen dat er kennis verloren gaat en er een verschil ontstaat tussen de taal binnen de IT en de taal in het bedrijf.

Het ICT systeem wordt zo een werkend model van de core business van het bedrijf. Dit zorgt ervoor dat ICT in lijn blijft met de organisatie: Het systeem is consistent met het bedrijf. Hierdoor kunnen wijzigingen sneller gerealiseerd worden.

Waarom Domain-Driven Design in plaats van andere modelleertechnieken?