Iedereen is het eens over het principe: modelleer het domein voordat u de architectuur tekent. In de praktijk houdt het zelden meer dan twee sprints stand voordat het team terugvalt op wat het kent.
Dit is geen gebrek aan discipline. Het is een verwarring van niveaus.
Het domeinmodel en de doelarchitectuur zijn geen opeenvolgende stappen van dezelfde oefening. Het zijn twee fundamenteel verschillende oefeningen — met verschillende tools, verschillende deelnemers en verschillende doelstellingen. Ze verwarren garandeert dat uw nieuwe architectuur de beperkingen van de oude reproduceert.
Probleemruimte en oplossingsruimte — mechanica, geen filosofie
Het onderscheid is niet conceptueel. Het is operationeel.
Het domeinmodel behoort tot de probleemruimte: het beschrijft wat uw organisatie doet, onafhankelijk van enig systeem. Wat zijn de echte bedrijfsprocessen? Welke regels bepalen die processen? Wie is verantwoordelijk? Dit analyseniveau kent geen databasetabellen, microservices of migratiebeperkingen. Het kent alleen de operationele realiteit.
De doelarchitectuur behoort tot de oplossingsruimte: zij beschrijft hoe technische systemen die realiteit zullen bedienen. Welke services, welke API’s, welke patronen (CQRS, event sourcing, bounded contexts) om de bedrijfsregels te implementeren die op het vorige niveau zijn geïdentificeerd?
| Domeinmodel | Doelarchitectuur | |
|---|---|---|
| Vraag | Wat doet de organisatie werkelijk? | Hoe zal technologie die realiteit bedienen? |
| Niveau | Probleemruimte | Oplossingsruimte |
| Deelnemers | Domeinexperts, product owners | Architecten, tech leads |
| Tools | Event storming, context mapping | C4-diagrammen, ADR’s, bounded contexts |
| Beperking | Geen — bewust | Budget, bestaande stack, team |
| Output | Ubiquitous language, bounded contexts | Service map, migratieplan |
De volgorde is niet onderhandelbaar. Het domeinmodel moet de doelarchitectuur voorafgaan — niet omdat het elegant is, maar omdat zonder het uw bounded contexts uw IT-organogram weerspiegelen, niet uw bedrijfsrealiteit.
Wat teams in de plaats doen — en waarom dat rationeel is
In de praktijk is dit wat er gebeurt in de meeste moderniseringsprojecten.
Het team begint met een domeinmodelleringsworkshop. Drie dagen event storming, post-its overal, energie in de kamer. Dan start de eerste deliverysprint. De backlog groeit. Stakeholders willen demo’s. De CTO zit gevangen tussen de druk van delivery en de achterstand van onafgemaakt domeinmodellering.
Bij de derde sprint wordt het domeinmodel stilletjes een vermomd doelarchitectuur. Bounded contexts spiegelen de modules van de bestaande ERP. De ubiquitous language raakt besmet met het legacy-vocabulaire. U begint te horen “ja maar in ons huidige systeem is het zo gestructureerd” — en niemand bevraagt dat “zo.”
Dit gedrag is rationeel. De CTO staat voor echte beperkingen: een team dat moet leveren, managers die vooruitgang willen zien, een budget dat geen zes maanden theoretisch modelleren dekt. De druk om vast te houden aan wat bestaat is structureel onvermijdelijk.
Het probleem is niet de bereidheid. Het is de opzet.
De symptomen van het kortsluiting
Wanneer domeinmodellering is kortgesloten, verschijnen de signalen maanden later — vaak na de livegang.
Bounded contexts spiegelen het organogram. Als uw services exact overeenkomen met uw huidige IT-teams, is dat verdacht. Bounded contexts moeten de bedrijfsrealiteit weerspiegelen, niet de bestaande organisatorische grenzen.
De ubiquitous language is besmet door het legacy. Ontwikkelaars en domeinexperts spreken over hetzelfde concept met verschillende termen. Of erger: ze gebruiken dezelfde term voor verschillende concepten. Dat is het teken dat domeinmodellering aan de oppervlakte is blijven steken.
Bedrijfsregels zijn verspreid over de code. Zonder geformaliseerd domeinmodel eindigen bedrijfsregels in technische lagen — SQL, validaties in controllers, condities in event handlers. Onmogelijk te onderhouden, onmogelijk uit te leggen aan domeinexperts.
De migratie reproduceert het bestaande. Module voor module, tabel voor tabel kopieert het nieuwe systeem het oude met een nieuwe stack. Nieuwe technologie, dezelfde beperkingen.
Ik heb dit patroon gezien in projecten van €1,5M, op tijd opgeleverd, waarbij gebruikers vanaf dag één van de livegang gefrustreerd waren. Dat was geen delivery-falen. Het was een ontwerpfalen.
Hoe het te laten overleven in contact met delivery
Domeinmodellering sterft onder de druk van delivery omdat het als een fase wordt gepositioneerd — met een begin, een einde en een overdracht. Dat is het verkeerde model.
Scheid de twee horizonten in de tijd. Domeinmodellering moet delivery met minstens vier tot zes weken voorafgaan. Als de event storming-workshop tegelijk met de eerste sprint begint, heeft het geen kans. Leveringsdruk consumeert altijd abstractie.
Bescherm domeinmodellering tegen contingentie. Iemand moet verantwoordelijk zijn voor het handhaven van de integriteit van het domeinmodel gedurende het hele project — ongeacht de sprintdruk. Die rol is niet die van de tech lead die diep in delivery zit. Het is typisch een architect of externe consultant die niet gevangen zit in de dagelijkse uitvoering.
Valideer met domeinexperts, niet met ontwikkelaars. De ubiquitous language wordt gebouwd met degenen die de bedrijfsprocessen beleven, niet met degenen die ze zullen coderen. Als uw event storming alleen ontwikkelaars in de kamer heeft, modelleert u uw systeemmodel, niet uw domeinmodel.
Test tegen echte randgevallen. Voordat u naar de doelarchitectuur gaat, test u het domeinmodel tegen uw meest complexe situaties — uitzonderingen, randgevallen, regels die tegenstrijdig lijken. Daar verschijnen de lacunes, niet in de nominale stromen.
Documenteer het “waarom” van elke bounded context. Elke bounded context moet in één bedrijfszin uitlegbaar zijn, zonder DDD-jargon. Als u het niet aan een bedrijfsdirecteur kunt uitleggen, heeft u een technisch artefact gemodelleerd, geen bedrijfsconcept.
Dus, concreet
Als u CTO bent van een lopend moderniseringsproject, één directe vraag: wie in uw team is verantwoordelijk voor de integriteit van het domeinmodel vandaag?
Als het antwoord “niemand” of “iedereen” is — lost het domeinmodel zich al op in de doelarchitectuur.
Het probleem is niet dat uw team niet weet hoe DDD te doen. Het is dat de opzet domeinmodellering niet beschermt tegen de druk van delivery. De tech lead die sprints superviseert kan niet tegelijkertijd de analytische afstand handhaven die nodig is om de probleemruimte intact te houden.
Dat is precies waar externe betrokkenheid waarde heeft — niet om het team te vervangen, maar om de rol te vervullen die de interne structuur niet kan vervullen: de integriteit van het domeinmodel handhaven terwijl delivery vooruitgaat.
Dat is het eerste wat ik bekijk in een Architectuur Assessment: bestaat het domeinmodel onafhankelijk van het huidige systeem, of is het al een projectie van wat bestaat.
Als u CEO bent in plaats van CTO en u een moderniseringsproject voorbereidt, dit artikel behandelt dezelfde dynamiek vanuit de bedrijfskant →