Ontwerp voor het probleem, niet voor de oplossing, met Kenny Baas-Schwegler

Satisfying Software – Kenny Baas-Schwegler

Domeinen en subdomeinen: de supermarktmetafoor

Gien: Hoe leg jij mensen het verschil uit tussen een domein en een subdomein?

Kenny: Mijn manier om het uit te leggen begon bij een running gag in de DDD-community over tomaten — biologisch gezien is een tomaat een vrucht, maar in de supermarkt is het een groente, en in het theater is het feedback. Dat leek me een interessante metafoor om verder uit te werken. Een domein is als een gang in een supermarkt, of de hele supermarkt zelf, afhankelijk van de grootte. Boven de gang hangt bijvoorbeeld "Aziatische voeding", en daarbinnen heb je afdelingen — Japans, Indonesisch, Indiaas. Die afdelingen zijn de subdomeinen. Een korte definitie van een domein of subdomein is: waar kennis gecategoriseerd wordt, waar problemen leven die specifieke kennis vereisen.

Gien: Ik zeg meestal dat het een kennissfeer of een activiteitsgebied is. Dat is bewust vaag, omdat het concept zelf vaag is — het is echt moeilijk om te zeggen waar een domein begint en eindigt. Het tomatenverhaal illustreert dat ook goed: als je je alleen op het woord "tomaat" focust, vind je het op drie verschillende plaatsen in de winkel. Daarom moet je naar de kennissfeer kijken in plaats van naar het label.

Kenny: Precies. Alleen op het woord focussen heeft weinig zin. Je wilt vragen: wat zijn de problemen, welke kennis is hier nodig?

Van subdomeinen naar bounded contexts

Gien: Hoe kom je van de supermarktgang bij een bounded context?

Kenny: Daar wordt de metafoor wat troebel. Je kunt de producten in de gang zien als bounded contexts — het zijn oplossingen voor de problemen die het subdomein vertegenwoordigt. Een bounded context is een oplossing voor een specifiek probleem. Het subdomein categoriseert de problemen en de kennissferen; de bounded context is hoe je een van die problemen oplost in software. Maar daar loopt de metafoor spaak, want een supermarkt is niet echt een complex domein in de DDD-betekenis. Toch krijg je zelfs in een eenvoudige winkel interessante vragen — baksoda ligt zowel in de gang met schoonmaakmiddelen als in de bakgang, omdat het in allebei een probleem oplost. Precies dat soort ambiguïteit kom je ook tegen in softwareontwerp.

Gien: Voor mij is een bounded context een instrument om complexiteit te beheersen — een expliciete grens die je bewust trekt, en waarbinnen je een specifiek probleem oplost. Daar schiet de metafoor tekort.

Kenny: Klopt. Dat is de echte essentie van waarom bounded contexts bestaan, en de supermarkt kan je daar niet helemaal naartoe brengen.

Subdomeinen en bounded contexts hoeven niet samen te vallen

Gien: Wat ik blijf zien, is dat bedrijven hun subdomeinen en bounded contexts netjes genest willen — een subdomein bevat zijn bounded contexts in een keurige hiërarchie. Maar er is geen een-op-eenrelatie tussen beide, toch?

Kenny: Nee — het kunnen er één, twee of drie zijn. Het is een ander soort grens. Zeggen dat subdomeinen en bounded contexts moeten samenvallen, is zoals zeggen dat landsgrenzen en taalgrenzen moeten samenvallen. In Nederland spreken we Nederlands, maar vlak bij de Duitse grens spreken mensen Duits, en in België is Duits zelfs een officiële taal. Lands- en taalgrenzen vallen niet samen, en ze proberen te forceren zou absurd zijn.

Gien: Als ontwerper heb ik me precies om die reden nooit veel op subdomeinen gefocust — ik had er geen controle over. Mijn instrument was de bounded context, en daar begon ik. Maar veel bedrijven zijn gefascineerd door het juist krijgen van hun subdomeinen. Waar komt dat vandaan?

Kenny: Ik denk dat mensen "domain-driven design" horen en aannemen dat de eerste stap is om de domeinen te definiëren. En daar zit iets in, maar de domeinen in organisatorische zin vallen niet noodzakelijk samen met de domeinen in de DDD-betekenis. Het organogram bestaat om mensen en budgetten te beheren, niet om softwareoplossingen te beheren. De DDD-domeinen zijn eerder ontwerpinput: je modelleert ze, en dan vraag je je af hoe je je teams en bounded contexts zou herorganiseren om ze beter te laten aansluiten — goed wetende dat je nooit een perfecte match krijgt, en dat is prima.

Gien: In grote ondernemingen is het gesprek over domeinen vaak politiek. Teams krijgen budget vanwege hun domein. Het gaat minder over kennis categoriseren en meer over organisatorisch eigenaarschap.

Kenny: Ja. En zodra de markt verschuift — stel dat een bank beslist om het onderscheid tussen particulier en zakelijk bankieren te laten vallen en in plaats daarvan een digitale bank te worden — breekt je hele domeinindeling van de ene dag op de andere. Het is altijd een tijdelijk ontwerp. Wat telt, is dat je het als een richting behoudt om naartoe te werken, niet dat je het als een vaste structuur behandelt.

Bounded contexts ontwerpen: focus op interactie, niet alleen op structuur

Kenny: Barry O'Reilly heeft het erover dat we te veel gefocust zijn op objecten en structuur — dat gaat helemaal terug tot Plato. Objectgeoriënteerd ontwerp ging oorspronkelijk over hoe objecten met elkaar interageren, niet over wat de objecten zijn. Hetzelfde geldt voor Team Topologies: mensen focussen op de teamvormen, terwijl de echte waarde zit in het modelleren van de interacties tussen teams. En zo is het ook met het ontwerpen van bounded contexts — focus op hoe bounded contexts met elkaar interageren via strategische patronen, in plaats van op de bounded contexts zelf. De structuur volgt uit die interactie.

Gien: Ik focus wél op de bounded contexts zelf, maar terwijl ik ze ontwerp, kijk ik altijd ook naar de interactie. Wat je wilt, is zoiets als bounded contexts van het Goldilocks-formaat — groot genoeg dat een team een coherent domeinmodel en een coherente taal kan vasthouden zonder dat ambiguïteit weer binnensluipt, maar niet zo klein dat je complexiteit gewoon naar de integratielaag verhuist.

Kenny: Precies. En ik zou eraan toevoegen: stel niet alleen het benoemen uit, maar ook het te veel structureren. Als je te vroeg naar structuur convergeert, kun je gaten niet meer opvullen met nieuwe creatieve ideeën. Chaos voedt creativiteit. Zodra alles een naam en een hokje heeft, stop je met divergeren.

Een echt voorbeeld: DHL en het adresprobleem

Kenny: Bij DHL is er een interessante case rond adresvalidatie. Leveringen op het juiste adres krijgen is echt moeilijk — alleen al in België heb je straten met namen in het Nederlands, het Frans en het Duits. Wat vroeger gebeurde: een pakje werd opgehaald, er werd een leveringspoging gedaan, het bleek onbestelbaar, en het werd doorgestuurd naar een backofficelokaal waar iemand het adres handmatig rechtzette. Heel laat in de waardestroom.

We vroegen ons af: wat als we adresvalidatie in plaats daarvan naar het begin van het proces verhuizen? Twee bounded contexts uit twee verschillende operationele domeinen — een aan het begin, een aan het einde — werden herontworpen als de verantwoordelijkheid van één team. Het team dat het probleem aan het begin opvangt, is nu hetzelfde team dat vroeger de gevolgen aan het einde moest opvangen, dus ze hebben alle reden om te optimaliseren. Dat herontwerp kon alleen gebeuren door naar de waardestroom te kijken en te vragen welke bounded contexts moesten verhuizen, ongeacht in welk organisatorisch domein ze oorspronkelijk zaten.

Gien: Dat is een goed voorbeeld van waarom softwareontwerp losgekoppeld moet zijn van het organogram. In een biotechbedrijf waar ik werkte, kwamen vloeistofoverdrachten — een kleine hoeveelheid vloeistof opnemen en verplaatsen — in bijna elk deel van het domein voor. Als je een-op-een met de bedrijfsdomeinen zou modelleren, zou je die logica in elke service gedupliceerd hebben. In plaats daarvan maak je één bounded context voor vloeistofoverdrachten, met een eigen domeinmodel en een eigen taal, en laat je die alle domeinen bedienen die hem nodig hebben.

Bounded contexts benoemen: begin bij het probleem, niet bij de oplossing

Gien: Bij het benoemen van bounded contexts probeer ik een werkwoord te gebruiken in plaats van een zelfstandig naamwoord. Als je hem naar een ding noemt — "Factuur" — zoomen mensen in op de aggregate en beginnen ze te denken dat de bounded context gewoon een omhulsel voor die entiteit is. Als je hem noemt naar wat hij doet — "Factureren" — krijg je een veel beter gesprek over wat erin thuishoort.

Kenny: Mijn heuristiek gaat nog een stap verder: noem hem naar het probleem dat hij oplost in de probleemruimte, en maak de naam in het begin belachelijk lang. Neem een boekingssysteem voor een bioscoop — mensen noemen dat vaak "stoelreservatie". Maar dat is een oplossing, geen probleem. Wat is het eigenlijke probleem? Mensen willen stoelen kiezen voor een voorstelling. Maar ook: de bioscoop wil vol raken — je kunt geen lege stoel laten tussen twee boekingen. Het probleem is dus rijker dan "stoelreservatie". Iemand noemde een bounded context ooit "het bioscoopoppervlak opvullen", en daar was ik dol op. Het kadert de zaken meteen anders. Als je alleen denkt aan iemand die een stoel kiest, bouw je een stoelkiezer. Als je denkt aan een bioscoop vullen, begin je heel andere vragen te stellen.

Gien: Dus "factureren" wordt zoiets als "vastleggen welke bedragen ons verschuldigd zijn".

Kenny: Precies. Begin met die mondvol. Mensen zullen het uiteindelijk inkorten, en dat is prima — maar lang beginnen houdt je in de probleemruimte. Kort beginnen katapulteert je meteen naar een oplossing die misschien niet de juiste is.

Benoem dingen niet te vroeg — of helemaal niet, als het moet

Gien: Teams willen vaak al na de allereerste ontwerpsessie namen vastleggen, en behandelen die eerste versie als het definitieve antwoord. Maar een eerste versie is nooit het beste ontwerp. Je moet itereren — naar de relaties kijken, nagaan hoeveel teams je nodig zou hebben, proberen een domeinmodel te bouwen binnen de grens en kijken of het überhaupt steek houdt. Soms is dat niet zo, en dat is nuttige informatie.

Kenny: Als mensen dingen te vroeg benoemen, begin ik bewust andere woorden te gebruiken om wat verwarring te zaaien. Domeinexperts vertellen je snel of een woord juist of fout is. Het veroorzaakt wat ongemak, maar dat ongemak is productief — structuur die te vroeg komt, sluit creatieve mogelijkheden af.

Gien: Ik had een case waarin een bedrijf volledig vastzat op het woord "campagne". Het dook overal op, betekende voor elk team iets anders, en elke poging om het te definiëren ontaardde in een politiek dispuut. Uiteindelijk begon ik placeholdernamen te gebruiken — een dinosaurus en een krokodil — gewoon om de gehechtheid te doorbreken en wat spanning weg te nemen. Zodra je loskomt van het label, kun je echt ontwerpen.

Kenny: Als je echt niet tot een naam kunt komen, noem het dan iets wat mensen zullen willen veranderen. Ik gebruikte ooit "de B&B Vol Liefde-bounded context", naar een Nederlands tv-programma. De helft van de groep had er nog nooit van gehoord, de andere helft keek er elke dag naar. Ik was er zeker van dat het snel hernoemd zou worden. Dat is net de bedoeling. En als je echt nog niet weet wat het probleem is, noem het dan gewoon een placeholder — maar zorg dat het uiteindelijk verandert.

De rant: naar oplossingen springen voor je het probleem begrijpt

Gien: Wat frustreert je nog altijd aan domeinen, subdomeinen en bounded contexts in de praktijk?

Kenny: Twee dingen. Het eerste is het aanhoudende debat in de DDD-community over probleemruimte versus oplossingsruimte. Dat onderscheid is enorm belangrijk, omdat je zo makkelijk in de val trapt om oplossingen te ontwerpen voor je het probleem begrepen hebt. Als ik bij een bedrijf binnenstap en ze zeggen dat ze meer aan DDD willen doen, vraag ik: wanneer heb je voor het laatst met een domeinexpert gesproken? En dan wordt het stil.

Ik zat onlangs in een sessie waar een team wist dat er een probleem was dat fouten veroorzaakte — dat wisten ze al maanden — maar ze wilden het niet analyseren, wilden het niet visualiseren, en sprongen meteen naar oplossingen zonder te begrijpen hoe het probleem zich eigenlijk voortplantte. De visualisatie, samen gemaakt, is waar het begrip vandaan komt. Die overslaan leidt bijna altijd ergens slechter naartoe.

De tweede frustratie is wat er gebeurt zonder feedbackloop tussen engineering en de business. Als je in een codebase een klasse vindt die iets als RefactorPatternManagerClass heet, dan kijk je naar een engineer die een concept moest toevoegen dat nog geen naam had in de domeintaal — en niemand die teruggekoppeld heeft naar de domeinexperts om dat op te lossen. Rebecca Wirfs-Brock en Matthias Verraes hebben daar goed over geschreven: soms moet je wel degelijk nieuwe concepten toevoegen, maar domain-driven design doen zonder die feedbackloop maakt de zaken mettertijd slechter, niet beter. Ook de business moet haar taal laten evolueren. Dat is moeilijk, het is sociaal, en het is min of meer waar we het boek over schreven.

Wat betekent satisfying software voor jou?

Kenny: Als ik dit beantwoord, denk ik niet aan de software — ik denk aan een team. Een van de laatste teams waarmee ik werkte, had 14 mensen die één grote ball of mud onderhielden. In achttien maanden hebben we die ontleed in 14 bounded contexts. Ze schreven er een casestudy over in het boek van Nick Tune.

Wat bevredigend was: een ruimte binnenstappen, naar een bord met metrieken kijken — bedrijfsmetrieken die de engineers zelf hadden opgezet — en ze een daling zien opmerken, die naar de code herleiden en ze in vijf minuten oplossen. Gebruikers hebben het nooit geweten. De klant heeft het nooit geweten. Het team had het probleem volledig in handen, omdat ze het domein goed genoeg begrepen om precies te weten waar ze moesten kijken. Iemand had een typfout gemaakt. Opgelost, uitgerold, klaar.

In het hele gesprek dat tot die oplossing leidde, gebruikte niemand ook maar één technische term. Ze praatten over het bedrijfsprobleem. En de product owner in dat team beheerde geen backlog — hij bracht opportuniteiten binnen, en de engineers gaven weerwerk met data: volgens wat we weten over het gedrag van gebruikers is dit niet de beste oplossing — maar wat als we dit in plaats daarvan doen? Dat gesprek was echt gelijkwaardig. Geen Scrum, geen ceremonie. Gewoon mensen die het probleem begrepen en er rechtstreeks aan werkten.

Zo ben ik 14 jaar geleden in deze sector terechtgekomen. In mijn eerste maand kreeg ik een tweedaagse cursus over het bedrijfsdomein, en gebruikers zaten naast me om me te vertellen wanneer mijn code het verkeerde probleem oploste. Dat voelde als de norm. Software die een echt bedrijfsprobleem oplost, die je ziet werken, en die je binnen die volledige feedbackloop houdt — zo ziet satisfying software eruit.