Webinar: domeinmodellen ontwerpen met de business in gedachten

Stijn Vannieuwenhuyse legt uit hoe je domeinmodellen ontwerpt met de business in gedachten.

Om Eric Evans te parafraseren is een domeinmodel:

• een systeem van abstracties

• die een geselecteerd aspect van een domein voorstellen

• en gebruikt worden om problemen in dat domein op te lossen

Om ervoor te zorgen dat het model waarde oplevert, moeten alle belangrijke business stakeholders het model begrijpen en er eigenaar van zijn. Als het verborgen zit achter de deur van engineering, verliezen teams een deel van zijn nut.

De uitdaging voor teams is dus om dit recht te zetten en het model centraal te stellen in hoe development en IT samenwerken. Teams die daarin slagen, hebben er baat bij: minder misverstanden die tot in de code doordringen, minder dure herwerking en snellere oplevering.

Wat je uit deze video leert:

• Waarom een model de werkelijkheid niet moet nabootsen

• Wat er in een domeinmodel thuishoort (met praktijkvoorbeelden van wat werkt)

• Hoe je gedrag in je model opneemt (niet alleen datastructuren)

• Hoe je ervoor zorgt dat de business je model begrijpt (en er mede-eigenaar van is)

• Wanneer je een model splitst (en waarom bounded contexts ertoe doen)

Voor wie is dit?

Deze sessie is bedoeld voor mensen die de samenwerking tussen business en development willen verbeteren (bv. architecten, developers, technical leads, managers).

Sessieleider:

Stijn Vannieuwenhuyse is senior consultant bij Aardling. Hij helpt klanten in uiteenlopende sectoren, waaronder gezondheidszorg, financiële dienstverlening en de automobielsector. Daarvoor was hij Head of Engineering bij Teamleader.

Bewerkte transcriptie van de presentatie

We hebben allemaal mentale modellen — en die verschillen vaak

Laat me beginnen met een kleine anekdote over mijn zoon. Hij is bijna 10, en onlangs begon hij interesse te krijgen in het nieuws volgen. Een paar weken geleden zocht hij een nieuwsprogramma in de tv-app en vond het niet. Hij vroeg waar het nieuws van vandaag was, en ik zei hem dat het nog niet uitgezonden was. Ik zag zijn brein kortsluiten. In zijn wereld betekent tv-kijken kiezen uit een bibliotheek — een catalogus waar je altijd uit kunt putten. Voor mij, toen ik opgroeide, was televisie lineair. Een tijdlijn. We hadden het over hetzelfde toestel, misschien zelfs dezelfde activiteit, met dezelfde woorden — maar we hadden totaal verschillende mentale modellen.

Dat komt niet alleen doordat hij een kind is. Zo geven mensen betekenis aan de dingen. We bouwen voortdurend modellen in ons hoofd om over de wereld te redeneren. En daar wil ik het vandaag over hebben.

Wat is een model eigenlijk?

Neem een metrokaart. Iedereen kan er een netwerk mee navigeren, en toch is ze geen accurate weergave van de werkelijkheid. De afstanden kloppen niet. De hoeken van de lijnen komen niet overeen met waar ze werkelijk lopen. De bochten weerspiegelen de realiteit niet. En toch werkt het — omdat ze ons een mentaal model geeft. Lijnen, richtingen, kleuren, nummers, haltes, overstappen. We denken in termen van hoeveel haltes en wanneer we van lijn moeten wisselen.

Het mentale model dat we hebben is veel belangrijker dan de voorstelling die voor ons ligt. De tekening drukt alleen ideeën uit. Zonder die onderliggende ideeën betekent de tekening niets.

Je ziet ook dat hetzelfde mentale model op verschillende manieren uitgedrukt kan worden voor verschillende doeleinden. Er is een versie van de kaart die maar één lijn toont — die waarop je zit. Er is een versie die omleidingen toont bij onderhoudswerken. Je kunt zelfs uitleggen hoe je door het netwerk navigeert zonder enige visuele voorstelling, gewoon door erover te praten.

Modellen zijn dus abstracties — mentale constructies in ons hoofd. Het zijn geen weerspiegelingen van de werkelijkheid, en ze zijn niet tastbaar. Soms drukken we een model uit als iets tastbaars, zoals een kaart, maar het model zelf blijft conceptueel. En een model is geen concrete oplossing. Als je honger hebt, wil je eten — maar eten is niet het model.

Een model vangt alleen geselecteerde delen van de werkelijkheid. De delen die nuttig zijn om een specifiek probleem op te lossen. En als het probleem genoeg verandert, heb je misschien een ander model nodig. Zouden onderhoudsmedewerkers dezelfde metrokaart gebruiken als reizigers? Zouden shiftplanners voor treinbestuurders dezelfde gebruiken?

Wat er gebeurt als mensen niet hetzelfde model delen

Als je naar een doos kijkt die verzonden moet worden, denkt de ene persoon aan de afmetingen en het gewicht en welk voertuig ze kan vervoeren. Een andere denkt aan de inhoud — is ze breekbaar, wat is ze waard. Twee mensen, twee verschillende mentale modellen, allebei volkomen redelijk.

Schaal dat op naar een groep mensen, en het wordt een serieus probleem. Het is moeilijk om elkaar te begrijpen, moeilijk om op dezelfde golflengte te komen. Voor mij gaat modelleren over uitdrukken hoe we onze versie van de werkelijkheid interpreteren en ons afstemmen op een gedeeld model — een waar iedereen aan bijdraagt, en dat uiteindelijk ieders denken in dezelfde richting stuurt.

Wanneer die afstemming in hokjes zit — de ene groep met het ene model, een andere groep met een ander — begin je wrijving te ervaren. Iemand vindt een wijziging klein; de andere groep ziet er een grote impact in. Je belandt in eindeloze vergaderingen over vereisten. IT levert het verkeerde op. Schaduwsystemen duiken op in Excel. De architectuur takelt af. Niet omdat mensen koppig zijn. Maar omdat ze vanuit verschillende modellen werken.

Het gedeelde model: wat maakt het goed

De oplossing is één gedeeld model. Een van de belangrijkste boodschappen die ik wil overbrengen, is dat het model dat het ontwikkelteam in zijn code uitdrukt, ook gedeeld moet worden met de business. Modellen worden vaak gemaakt door het ontwikkelteam — maar we hebben gedeeld eigenaarschap nodig. De business moet het model valideren, begrijpen en als logisch herkennen. Er mag geen vertaallaag zijn. Dat is een van de belangrijkste kwaliteiten van een goed model.

Wat maakt een model nog meer goed? Laat me een paar kwaliteiten overlopen.

Een goed model maakt het probleem beheersbaar. De werkelijkheid is een rommeltje. De manier waarop we tijd meten is een goed voorbeeld. Jaren en dagen zijn gebaseerd op de rotatie en de baan van de aarde — maar die baan verschuift. Ons tijdmodel negeert dat. We gebruiken een gemiddelde daglengte en ronden het jaar af naar 365 dagen. Zo werkt de werkelijkheid niet. Maar 1.460 dagen lang hoeven we er niet aan te denken — en op de 1.461ste dag patchen we het met een schrikkeldag. Het doel is geen volledig of precies model. Het doel is een nuttig model. We verminderen de cognitieve belasting door alleen de details te behouden die ons echt helpen redeneren.

Een goed model laat je dingen doen die je vroeger niet kon. Soms geeft de werkelijkheid ons niet genoeg detail. Als we alleen licht en donker en seizoenen hadden, konden we niet zeggen "we spreken af om 12:30". Uren en minuten zaten niet in de werkelijkheid — we hebben ze ingevoerd als abstracties om een probleem op te lossen. Maar die abstracties moeten ook voor de business zinvol zijn. Je kunt geen technische oplossing opleggen en verwachten dat de business een model dat daarop gebouwd is, begrijpt en valideert.

Een goed model comprimeert betekenis. Stel je voor dat je een deadline moet omschrijven als "vóór de derde keer dat het daglicht verschijnt na de eerste volle maan na het bloeien van de witte bloesembomen van de vroege lente". Zonder eigen namen voor concepten — dagen, weken, maanden — wordt elk probleem beschrijven onmogelijk omslachtig. Een goed model levert de woordenschat die nodig is om problemen en oplossingen beknopt te beschrijven. Er is misschien een leercurve de eerste keer dat iemand de abstracties tegenkomt, maar elk gesprek daarna gaat sneller. We moeten de zelfstandige naamwoorden vinden die hele zinnen vervangen.

Een goed model scherpt je denken aan. Het doet je vragen stellen over je aannames. Het creëert voorspelbaarheid. Het wordt vanzelfsprekend. Als de abstractie juist zit, kun je erover redeneren, erover discussiëren en beslissingen nemen op een hoger niveau. Een goed voorbeeld: in loonsoftware voor shiftwerkers, als een shift over middernacht loopt, is dat dan één werkdag of twee? Geldt er overwerk als je laat werkt? Ons standaardmodel van een "dag" helpt hier niet. Maar als we de dag binnen dit model herdefiniëren als een "werkdag", worden die vragen beantwoordbaar. Nieuwe vragen komen boven, en aannames waarvan we niet wisten dat we ze maakten, worden zichtbaar. We beginnen op een ander niveau te denken.

Hoe een model er echt uitziet — zijn dimensies

Veel mensen verwarren een voorstelling van een model met het model zelf. Ze blijven steken in denken in datastructuren en diagrammen. Maar het onderliggende mentale model is het model. En dat mentale model heeft meerdere dimensies.

Er is structuur: concepten, relaties, eigenschappen. Er is gedrag: wat doet het model? Welke businessregels en logica moet het bevatten? Er zijn de scenario's die het moet ondersteunen — en de scenario's die het uitdrukkelijk niet ondersteunt. En er is zijn interface: hoe de buitenwereld ermee omgaat, niet in termen van gebruikersinterface, maar conceptueel.

Neem een verzenddomein, waar een routeringsdienst de haltes opzoekt die een zending moet aandoen op basis van haar vertrekpunt, bestemming en aankomsttijd. Uit die beschrijving kunnen we zelfstandige naamwoorden halen: "itinerary" — een woord dat de business al gebruikt — en "route specification", een abstractie die we invoeren om het redeneren makkelijker te maken. Maar de werkwoorden zijn even belangrijk. De routeringsdienst vindt een itinerary voor een zending die voldoet aan haar route specification. Gedrag maakt evenzeer deel uit van het model als structuur. In mijn ervaring is het vaak belangrijker, en wordt het vaak over het hoofd gezien. De werkwoorden geven ook vorm aan de externe interface — hoe gebruikers of andere modellen met dit model omgaan.

We moeten de zelfstandige naamwoorden vinden die hele zinnen vervangen, maar we hebben ook de werkwoorden nodig om die naamwoorden te verbinden. Zodra we een goed model hebben, kunnen we er verschillende aspecten van belichten met verschillende voorstellingen — wat maar helpt om de boodschap over te brengen voor een bepaald doel. Maar één voorstelling is belangrijker dan de andere: de code. Daar wordt het model uiteindelijk uitgevoerd. We moeten het gedeelde conceptuele model zo getrouw mogelijk in code uitdrukken. Doen we dat niet, dan voeren we dezelfde wrijving als vroeger opnieuw in, alleen op een ander niveau.

Het datamodel is trouwens gewoon een andere voorstelling van hetzelfde model. Het moet het denken en het uitvoeren van de code ondersteunen — niet sturen.

Echte voorbeelden uit de praktijk

Laat me dit concreet maken met een paar voorbeelden uit mijn werk.

Ik werk met een financiële instelling die B2B-leningen verstrekt. Om een lening goed te keuren doorlopen ze verschillende stappen, elk een controlepunt. Als één controlepunt faalt, kan de lening niet toegekend worden. De doorbraak kwam toen we een controle niet langer als iets binairs behandelden — geslaagd of niet — maar ze modelleerden met drie toestanden: afgewezen, goedgekeurd, en een risico dat menselijk onderzoek vereist.

Die derde toestand veranderde alles. We beseften dat een afwijzing niet noodzakelijk een eindtoestand hoeft te zijn — ze kon herbekeken worden als er nieuwe informatie opdook. De gele, onderzoekende toestand was dringend en lag bij het risicoteam. Maar zodra er een afwijzing was, verschoof het initiatief — het was niet langer de taak van het risicoteam om erachteraan te zitten, maar die van de accountmanager of de klant. Twee verschillende doelen, twee verschillende krachten, expliciet gemaakt door die derde toestand in te voeren. Het model scherpte het denken aan en legde organisatorische dynamieken bloot die voordien onzichtbaar waren.

Een ander domein dat we in trainingen gebruiken, is een deelfietssysteem. Iemand voegt een fiets toe aan een station, plant een rit, gaat naar het station, ontgrendelt de fiets, rijdt, en parkeert hem aan een ander station. De belangrijkste businessregel: als je een rit plant, moet de fiets beschikbaar zijn wanneer je aankomt. De capaciteit op stationsniveau visualiseren hielp ons hierover te redeneren. Een station begint leeg, er worden fietsen toegevoegd, iemand reserveert er een, de fiets wordt onbeschikbaar, de rijder neemt hem mee en parkeert hem elders — en pas wanneer de rit beëindigd is, wordt hij weer beschikbaar. Dat liet ons ook redeneren over randgevallen: een onderhoudsmedewerker die een fiets reserveert zodat niemand anders hem kan gebruiken.

We verkenden twee concurrerende modellen. In het ene reserveer je een specifieke fiets. In het andere reserveer je een plek aan een station, en beslist het station welke fiets het uitgeeft op basis van volgorde van aankomst, batterijniveau of schademeldingen. Beide visualiseren liet ons over de trade-offs redeneren.

In een derde voorbeeld — opnieuw de financiële instelling — bieden ze kredietlijnen aan bedrijven aan en wilden ze borgstellingen invoeren: een derde bedrijf staat borg voor een hoofdkredietnemer en verbindt zich ertoe de terugbetaling te dekken als dat nodig is. Ik begon de borgstelling te visualiseren als een relatie — de relatie zelf wordt het model. Van daaruit kwamen de relevante dimensies naar boven: ze heeft risicogoedkeuring nodig, beide bedrijven moeten tekenen, ze moet beperkt zijn in tijd en in budget, en we moeten controleren dat de twee bedrijven niet verbonden zijn met dezelfde persoon die fraude probeert te plegen. Door die dingen te visualiseren, kwamen de juiste gesprekken op gang. We leidden er ook de publieke interface uit af: je kunt een borgstelling opstellen, ze voorstellen aan een tegenpartij, ze aanvaarden of afwijzen, ze laten vervallen.

Als modellen te groot worden: splitsen is het antwoord

In realistische situaties zijn probleemgebieden groot. En bijna elk domein heeft concepten die alles lijken aan te trekken. In een verzenddomein lijkt alles met de zending te maken te hebben. Die modellen worden magneten — elke nieuwe vereiste wordt eraan toegevoegd, en het model wordt onbeheersbaar.

De oplossing is niet meer documentatie. De oplossing is splitsen. Je kunt splitsen op levenscyclus: een itinerary in ontwerp heeft andere regels en andere informatienoden dan een lopende. Je kunt splitsen op businessdoel: planning, audit picking en tracking draaien allemaal om een "zending", maar de details die elk nodig heeft, zijn totaal verschillend. Kleinere, meer gerichte modellen die naast elkaar bestaan en met elkaar interageren.

Netflix is een goed voorbeeld. Alles lijkt misschien met een "show" te maken te hebben, maar in de praktijk ziet het concept show er heel anders uit naargelang wat je doet. De catalogus heeft een beschrijving en een cover nodig. Aanbevelingen hebben een andere doorsnede van informatie nodig. Afspelen heeft de videostream, de audiostream en je voortgang in de aflevering nodig. Favorieten zijn weer anders. Al die dingen hangen samen met hetzelfde onderliggende ding, maar het zijn echt verschillende modellen.

Als je meerdere teams hebt die aan verschillende gebieden werken, wil je een gedeeld model per verantwoordelijkheidsgebied — meerdere modellen die naast elkaar bestaan, interageren waar nodig, en elk op zich beheersbaar zijn.

De belangrijkste conclusies

Een model is een systeem van abstracties, geen diagram. Het is in de eerste plaats een mentaal concept. Al de rest — kaarten, code, documentatie — is er maar een uitdrukking van.

Goede modellen maken problemen beheersbaar, laten je dingen doen die je vroeger niet kon, comprimeren betekenis en scherpen je denken aan.

Modelleren gaat over mentale modellen op elkaar afstemmen. Het gaat niet over specifieke diagrammen produceren.

En als je maar één ding onthoudt: een model is een denkinstrument. Gebruik het ook zo.