“All models are wrong, but some are useful”

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 u003cemu003eevent stormingu003c/emu003e en daarop volgend u003cemu003emodel stormingu003c/emu003e. 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 u003cemu003eno upfront consensusu003c/emu003e: 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.rnrnBruikbaar betekent in de business: er is geld mee te verdienen. Exercities zoals u003cemu003estormingu003c/emu003e, 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 u003cemu003emodeling heuristicsu003c/emu003e. 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.rnrnEen domeingedreven design leidt als vanzelf tot een netwerk van kleine systemen, soms ook wel u003cemu003eactorsu003c/emu003e genoemd, die hun eigen doel behartigen. Deze architectuur is tegenwoordig ook technisch heel natuurlijk vorm te geven in het groeiende u003cemu003eInternet of Thingsu003c/emu003e, waarbij alle u003cemu003ethingsu003c/emu003e 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!