” Wij ontwikkelen maatwerk, web based,
back office- en middleware applicaties. “

Domain Driven Design: Samen met de klant dezelfde taal spreken

Op 22 november organiseert de Amsterdam PHP Meetup-groep samen met de Nederlandse Domain Driven Design (DDD-NL) Meetup-groep een evenement over Event Storming in het hoofdkwartier van True. Wij vroegen aan Jeroen van der Gulik, lead developer bij Isset Internet Professionals en mede-initiator van de DDD-NL-groep, wat de termen Domain Driven Design en Event Storming betekenen en wat je als (PHP-)developer op deze avond kunt leren. “In 4 uur tijd een heel proces beschrijven wat normaal gesproken in een 100-pagina tellend document staat die nooit iemand leest. ”

De vraag achter de vraag stellen

“Kort gezegd” legt Jeroen van der Gulik uit “Is Domain Driven Design een methode om op een andere manier te kijken naar het maken van software.”.

Volgens Jeroen wordt er bij veel softwareprojecten niet nagedacht over het daadwerkelijke probleem van een business, maar denken developers vooral aan de techniek. “De klant maakt het niet uit dat je alle code in een file zet of dat je een of andere monolithische architecture gebruikt. Het enige wat ze willen is dat jij hun probleem oplost. Het zijn niet de technieken die het probleem oplossen.”

Domain Driven Design biedt daarop een antwoord. Wat is het probleem en hoe kunnen we dat op de meest simplistische en minimale manier oplossen?

Volgens Jeroen gaat Domain Driven Design om het stellen van de vraag achter de vraag. “De kernvraag die bij softwaretrajecten bijna nooit gesteld wordt is: ‘waarom?’. Waarom wil je dit? Heel vaak kom je erachter dat het probleem van de klant niet terugkomt in de vraag die gesteld wordt. En heel vaak is de oplossing simpeler te bedenken dan aanvankelijk wordt gedacht. Daar kom je pas achter als je de waarom-vraag stelt. De kernvraag blijft: lost dit jullie business probleem op?”

Een gezamenlijk woordenboek

Een van de manieren om samen met de klant onduidelijkheden weg te nemen is om een gezamenlijk woordenboek op te stellen. Binnen Domain Driven Design heet dit: Ubiquitous language.

Jeroen: “Vrij letterlijk betekent dit: een taal zonder onduidelijkheden. Het doel van ubiquitous language is dat de developer zich gaat inleven in de denkwijze en taal van de klant. Zo voorkom je miscommunicatie.”

Als voorbeeld noemt Jeroen het bestelproces bij Amazon. Een order van een bezoeker op de Amazon website is zijn bestelling. Voor Amazon is een order een pakketje dat is gekocht en is betaald. De postbode ziet een order als een pakket dat naar een adres toe moet. Drie keer hetzelfde woord (order), maar iedere keer heeft die het een andere betekenis en een andere context.

“Als developer is dat ontzettend lastig. Je moet constant nadenken over de context en een vertaalslag maken naar de taal van de computer. Dat terwijl je vaak de context niet eens weet.”

Gebonden aan dezelfde context

Als je eenmaal de taal van de klant spreekt, is er nog zoiets als bounded context. Jeroen haalt het eerdere voorbeeld van Amazon weer aan. “In het geval van Amazon kun je spreken van drie bounded contexten, namelijk de context van de websitebezoeker, van Amazon en van het postbedrijf. Je zou er zelfs nog een vierde bij kunnen hebben; namelijk het magazijn dat de order verwerkt.”

“Voor de meeste opdrachtgevers is deze bounded context gesneden koek.” zegt Jeroen. “Maar als zij dit soort termen gebruiken zit er veel verborgen wijsheid in, zoals bijvoorbeeld jargon. Die gaan ze niet uitleggen, omdat ze er vanuit gaan dat jij ze al weet. Zij spreken elke dag met mensen die al bekend zijn met de termen en zijn zich van geen kwaad bewust dat ze dit doen.”.

Omdat je dezelfde taal gebruikt kan de klant ook snel reageren op de dingen die je bedenkt. Hij zal vanzelf acteren op de dingen die je gebruikt. Als jij hun taal begrijpt en naspreekt, gaan ze vanzelf zeggen: “Dat is niet hoe wij dit doen”. Dan kun je doorvragen; “Hoe doen jullie het dan wel?”

Visualiseren van het business probleem

Een van de manieren om Domain Driven Design naar de praktijk te brengen is via de modelleringstechniek ‘Event Storming’.

“Event Storming begint met een lege muur. Zie het als een leeg canvas. Iedereen die met de workshop meedoet begint stickies op te plakken. ‘Events’ noemen we dit: iets wat er gebeurt is in het systeem. Denk aan ‘UserRegistered’, ‘UserReceivedValidationEmail’, ‘UserValidatedEmail’.”.

Volgens Jeroen wordt het er een hoop duidelijk als je deze stickies op het lege canvas plakt. “Er ontstaat een process flow. Je ziet in een oogopslag hoe bijvoorbeeld een registratieproces werkt. Doordat het visueel is, ontstaan er gelijk vragen. Wat gebeurt er als de validatiemail niet aankomt? Wat gebeurt er als iemand twee keer met hetzelfde mailadres registreert?.”.

Omdat je Event Storming doet met mensen waar je het voor bouwt, krijg je direct antwoord op die vragen, vertelt Jeroen. “Hier zit een enorm krachtig mechanisme: de klant weet welke trade-offs er gemaakt zijn. Een developer hoeft niet meer zelf te bepalen wat belangrijk en onbelangrijk is. Door de techniek ontstaat duidelijkheid.”

Het is dus iets waar je alleen achter kunt komen als je dezelfde taal spreekt en het binnen dezelfde context van de klant bespreekt en/of plaatst. “De Domain Driven Design methodologie helpt daarbij. En het mooie is dat je het al binnen 4 uur kan realiseren.”

Event Storming gebruiken voor een ticketing systeem

Dat Domain Driven Design in de praktijk kan werken is iets wat Marc, developer bij True en tevens lid van de AmsterdamPHP- en DDNL Meetup-groep, kan bevestigen.

“Voor ons zusterbedrijf Multrix hebben we Event Storming ingezet om de ticketing tool te ontwikkelen.” Deze tool wordt gebruikt om de helpdesk van Multrix te helpen met het effectief afronden van supportaanvragen van klanten.

Marc geeft aan dat veel van de kennis van het True ticketingsysteem gebruikt kon worden voor de ontwikkeling van de software, maar dat er ook veel verschillen waren. “Er zat een hoop overlap in, maar ook afwijkingen”. De verschillen werden in kaart gebracht en op basis daarvan kon de tool verder worden ontwikkeld.

“Er kwamen heel veel duidelijkheden uit. Als die zonder uitleg bij ons terecht waren gekomen hadden we dat verkeerd geïnterpreteerd. Maar doordat je met z’n allen ernaar kijkt, krijg je een veel beter beeld van wat iemand daadwerkelijk bedoelt.”

Marc geeft dan ook blij te zijn dat de workshop op het True hoofdkantoor wordt gegeven. “Ik ga samen met collega’s naar de workshop. We kijken er naar uit om weer veel nieuwe dingen te leren die we in ons vakgebied toe kunnen passen.”.

22 november staat het True hoofdkantoor een avond in het teken van Domain Driven Design. Wil je erbij zijn? Meld je dan snel aan via Meetup.com. Er zijn nog maar een paar plekken beschikbaar.

Auteur originele artikel: Kilian Drewel

previous list next