Artikel

Complexiteit aanpakken met Domain-Driven Design

Zouden Skype, Facebook en Google use case specificaties, TOGAF, DYA of Zachman gebruiken? Of zijn deze megaondernemingen minder complex dan de ondernemingen waar wij zelf werken? Inmiddels is er een hele opleiding voor nodig om alleen al de gangbare architectuurmodellen, modelleertechnieken en bijbehorende tools te kennen en al helemaal om ze te kunnen gebruiken. Deze onnodige complexiteit kost substantieel meer dan dat het oplevert. In dit artikel wordt een eenvoudig alternatief gegeven waarmee vervolgens echte complexiteit, de complexiteit waarmee gebruikers te maken hebben, kan worden aangepakt.

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?

Categorie:   
Auteur(s)
afbeelding van viktorgrgic
Viktor Grgic
LeanArch b.v. - Eigenaar

Viktor Grgic is een zelfstandige Agile/Lean IT architect die in zijn werk als software architect Agile principes hanteert. Viktor heeft in zijn loopbaan als architect vele software projecten geleid. Onder andere leiding gegeven aan architectuurteam van Nieuw Handelsregister bij Kamer van Koophandel, lead SOA / integratie architectrol vervult bij ProRail en vele architecten gecoacht in hun werk. Viktor's werk kenmerkt zich door sterke focus op de mensen, eenvoud in alles, risico's onderkennen en realisme in wat met software mogelijk is. Viktor's expertise is met name service-orientatie / SOA, EAI, domein modellering, ontwikkelstraten, ontwikkelmethodieken en systeemontwikkeling van met name JEE systemen.

afbeelding van markvanholsteijn
Mark van Holsteijn
Xebia - senior consultant

Mark van Holsteijn is senior consultant bij Xebia.

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.