Klaar voor de toekomst met Domain Driven Design

Wij geloven in de Agile principes, waarbij je software iteratief ontwikkelt en stap voor stap beter maakt. Maar als je met complexe werkprocessen te maken hebt of een organisatie met meerdere businessunits, eventueel verspreid over meerdere landen, is het beter eerst de basis goed op de orde te krijgen voordat je aan user stories en user experience begint te denken. Daarvoor is Domain Driven Design.

Wat is Domain Driven Design?

Domain Driven Design helpt je software te maken die nauw aansluit bij je business of een verbeterde versie daarvan. Hiervoor beschrijven business experts en software developers samen de werkprocessen met alle ex- en impliciete regels en problemen die kenmerkend zijn voor een domein. Dit leidt uiteindelijk tot een conceptuele beschrijving van een domein, met afspraken over gebruikte termen. Dit domeinmodel staat op zich los van de software (database en code), maar zal wel vaak als basis daarvoor worden gebruikt. Het domeinmodel is ook basis voor de verdere communicatie over het domein, zoals het opstellen van requirements.

Het begint met de business

Domain Driven Design is niet zozeer een technische aanpak, maar vooral een procesmatige. Het begint allemaal met luisteren naar, discussiëren over en begrijpen van de manier waarop de business werkt of wil werken. De business en softwareontwikkelaars moeten elkaar precies leren begrijpen, net als de medewerkers binnen de organisaties. Door met elkaar de problemen te bespreken waartegen de business aanloopt, krijg je stap voor stap een eenduidig gezamenlijk beeld.

Ubiquitous language

Het is belangrijk dat alle medewerkers, stakeholders, programmeurs, projectmanagers, etc., dezelfde woorden voor dezelfde zaken gaan gebruiken. Daarom ontwikkel je bij Domain Driven Design samen een taal die iedereen begrijpt en waarmee iedereen hetzelfde bedoelt. De term hiervoor is 'ubiquitous language'. Dit leidt tot een conceptueel schema, met alle woorden die specifiek zijn voor een domein en de beschrijving van entiteiten en hun relaties en regels. Het is de bedoeling dat voor alle vormen van communicatie (user stories, meetings, e-mails, technische documentatie, planning, etc.) die woorden worden gebruikt.

Van woordenboek naar code

De termen en definities uit het woordenboek worden ook gebruikt in de code voor het domeinmodel. In deze laag van de software vertaal je de businessconcepten en de businessregels naar entities, value objects, aggregates, gedrag, services etc. Hierop kun je dan later de front-endoplossingen bouwen. Deze front-endoplossingen zullen door deze manier van werken en basisstructuur consistenter, stabieler en beter te onderhouden zijn. Bovendien staan alle businessregels bij elkaar, wat erg nuttig is als je later zaken wilt veranderen.

Meerdere modellen voor grotere organisaties

Grotere organisaties hebben vaak meerdere domeinen. Ook dan is Domain Driven Design goed toepasbaar, want je kunt als dat nodig is voor de verschillende domeinen binnen een organisatie verschillende modellen maken. Die modellen en daarmee ontwikkelde applicaties hebben dan ieder hun eigen focus en eigen taal. In DDD wordt dit “bounded context” genoemd. Via API’s kun je die applicaties vervolgens extern en intern integreren. Op deze manier zorg je dat je applicaties allemaal goed passen bij de domeinen die ze primair moeten ondersteunen.

Wanneer wel en niet

Uiteraard kost het tijd en geld om eerst met zijn allen te onderzoeken hoe de business werkt. Domain Driven Design is dan ook vooral nuttig als de business processen complex zijn of als ze dit waarschijnlijk gaan worden. Ook als de business veel veranderingen verwacht, maar nog niet weet welke precies, leg je met Domain Driven Design een goede basis voor toekomstige oplossingen. In die gevallen betaalt de inspanning die je levert aan het begin van het traject zich later terug. Software die niet doet wat de business wil of niet goed met veranderingen kan meegroeien, kost vaak nog veel meer geld.