Mensen die werkzaam zijn in de ICT hebben typisch een haat-liefde verhouding met modellen. En ja, ook deze eerste zin is al exemplarisch: wat bedoel ik met de term “modellen”? Hoe interpreteert u dit als lezer? Als u vooral mooie dames of heren voor ogen had: helaas. Het gaat hier om de wiskundige, technische variant. En dan nog is de kans klein dat we het over hetzelfde hebben. Taal heeft me altijd gefascineerd. Hoe mensen samenwerken ook. Logisch dat ik interesse had in een workshop domain driven design (DDD). Centraal stond de vraag ‘als het begrijpen van een domein en communiceren erover al zo lastig is, hoe kun je dan een systeem ontwerpen dat daar correct op aansluit?’
Ik kreeg de kans om bij mijn opdrachtgever deel te nemen aan een driedaagse inleiding op DDD door Mathias Verraes. Houd je van een mix van theorie en praktijk rondom dit onderwerp, gepresenteerd met een prettige zachte ‘g’ en afgestemd op de behoeften van de zaal: zoek hem dan op! Wat volgt is zeker geen uitputtende samenvatting, maar wel enkele inzichten die ik heb opgedaan naar aanleiding van deze workshop.
Hét model?
Mijn belangrijkste nieuwe inzicht is vervat in de titel van dit artikel: een uitspraak die wordt toegeschreven aan de statisticus George E.P. Box. Ik denk dat vele ICT-ers wel weten dat modellen vaak verkeerd zijn én tevens vaak hun nut hebben. We zoeken dan naar dat ene model wat wél goed is, waarin het domein dan toch echt op de juiste manier, met de juiste bewoording in is vervat. Maar uitgerekend dat is onze valkuil: geen enkel model is correct, maar juist voor zijn specifiek doel kan het wel erg bruikbaar zijn. Een domein is complex, veranderlijk en vooral op verschillende manieren interpreteerbaar. Een representatie daarvan maken om alle beoogde doelen binnen het domein te bewerkstelligen is in de regel ondoenlijk. Met meerdere modellen kan het wel lukken. Om hiertoe te komen helpt de DDD gedachte.
DDD in een notendop
DDD is geen “one design to rule them all”, maar veeleer een manier van denken waarmee je om kunt gaan met de domeincomplexiteit van alledag. Het gaat daarbij grotendeels om het volledig expliciet, helder en inzichtelijk maken van hoe het domein in elkaar zit. Een techniek die daarbij gebruikt kan worden is event storming en daarop volgend model storming. Deze specifieke brainstormtechnieken sluiten aan bij het karakter van het domein, waarin meerdere disciplines meerdere visies op de gemeenschappelijke omgeving hebben. Door allemaal tegelijk en op hetzelfde niveau alle relevante gebeurtenissen in het domein op te schrijven, ontstaat in een mum van tijd een vrij compleet beeld van wat er allemaal speelt en hoe het met elkaar samenhangt. Hierbij worden beproefde middelen als markeerstift, sticky note en papier gebruikt. Een belangrijk leerpunt tijdens de workshop was no upfront consensus: juist meerdere interpretaties, meerdere formuleringen, ieders eigen blik op hetzelfde is belangrijk. Maar oh, wat wilden we graag samen overleggen wat er op hét briefje moet komen staan. Wat is nou toch dé correcte verwoording? U voelt het wellicht al: ze waren geen van allen correct, maar sommige waren wel bruikbaar.
Bruikbaar betekent in de business: er is geld mee te verdienen. Exercities zoals storming, die liefst breed binnen het domein worden uitgevoerd, geven inzicht. Over relevante gebeurtenissen, over relaties, trends en processen. Over nog veel meer dingen, samen genoemd modeling heuristics. Het identificeren van deze aspecten dient als inspiratie voor wat, waar, hoe en wanneer bereikt moet worden. Doelen worden zo duidelijker en beter gestoeld op het achterliggende domein. Het bijpassende concrete model en (deel)systeem ontwerpen is dan relatief eenvoudig.
Een domeingedreven design leidt als vanzelf tot een netwerk van kleine systemen, soms ook wel actors genoemd, die hun eigen doel behartigen. Deze architectuur is tegenwoordig ook technisch heel natuurlijk vorm te geven in het groeiende Internet of Things, waarbij alle things over aardig wat (multi threaded) rekenkracht beschikken. In de ideale wereld werkt dat allemaal prachtig met elkaar samen. In werkelijkheid zul je ook in het technisch domein dezelfde uitdagingen tegenkomen als in het natuurlijke domein. Dezelfde technieken komen dan van pas: in de workshop hebben we ook ons eigen wereldje van systemen, talen en communicatiekanalen in een storm laten neerdalen. Ook daar zijn de nodige heuristics op los te laten. Ook daar kom je in een beperkte tijd al tot behoorlijk goed inzicht. Als bonus is dit inzicht daarna ook beter uit te leggen aan “dat andere domein”. Vanuit DDD zijn effectief bruggen te slaan naar de mensen die ‘nooit buiten de deur komen’ en v.v. naar hen die ‘niet technisch zijn’.
DDD buiten de notendop
Juist dat DDD zo algemeen toepasbaar is vond ik een prettig gevoel. Het sluit goed aan bij een event-driven systeem op basis van CQRS, met kleine actors en een functionele programmeerstijl. Maar het kan even goed objectgeoriënteerd worden toegepast. Technieken uit de workshop kunnen worden ingezet om in detail in te zoomen op een specifiek probleem, maar ook om een compleet domein in kaart te brengen. Daar gaat mijn abstracte ontwikkellaarshart sneller van kloppen, ik hoop dat van u ook. Deze inzichten zijn breed toepasbaar. Laten we dat dan ook doen!