Wat is DCB (Dynamic Consistency Boundary) en waarom zou je het gebruiken?

In een vorige post legden we uit wat event sourcing is: je bewaart niet enkel de huidige staat, maar elke gebeurtenis die ertoe heeft geleid, zoals een boekhoudkundig grootboek dat je nooit uitgomt.

Wat we daar bewust lieten liggen, is de bekendste beperking ervan. En net die beperking is de reden waarom DCB bestaat. In klassieke event sourcing leg je je consistentiegrens vast op het moment dat je je events modelleert, en die keuze ligt daarna grotendeels vast. Zodra een businessregel over twee van die grenzen heen snijdt, begint het te schuren. DCB haalt die starheid eruit. Hieronder leggen we uit hoe, met de echte begrippen maar zonder in code te duiken.

De beperking van klassieke event sourcing

In klassieke event sourcing is je consistentiegrens het aggregate: een afgebakend stukje van je domein (één klant, één bestelling, één product) met zijn eigen reeks events. Eén aggregate, één stream, één grens. Binnen die grens heb je sterke consistentie, bewaakt met een versienummer en optimistic locking: je leest tot versie N, en je schrijven slaagt alleen als niemand ondertussen al versie N+1 heeft toegevoegd. Simpel, en het schaalt goed, want elk aggregate staat op zichzelf.

De prijs is dat die grens vastligt tijdens de analyse, nog voor het ontwikkelen. Twee dingen die altijd samen moeten wijzigen, moeten in hetzelfde aggregate zitten. En een regel die over twee aggregates heen gaat, kun je niet in één transactie afdwingen. Het schoolvoorbeeld: een bestelling die zowel de voorraad van een product (het ene aggregate) als de kredietlimiet van een klant (het andere) raakt. Die twee kun je niet in één keer samen bewaken.

De gangbare uitwegen zijn allemaal omwegen. Eén reusachtig aggregate dat alles omvat, maar dat doodt parallellisme en wordt op den duur onbeheersbaar. Of een reserveringspatroon met een saga die de twee coördineert: dat werkt, maar voegt veel bewegende delen toe en een tussentoestand waarin het systeem even inconsistent is. En kies je je grenzen verkeerd, dan betekent rechtzetten dat je je events moet her-streamen: een migratie die je liever niet op een draaiend systeem uitvoert.

Wat DCB anders doet

DCB (Dynamic Consistency Boundary) maakt van consistentie geen vaste grens, maar een voorwaarde per commando, uitgedrukt als een query over je events.

Het werkt zo. Elk event krijgt tags mee, bijvoorbeeld product:123 en klant:456. Een consistentiegrens is dan niets meer dan een query over die tags. Voor een commando lees je de events die je beslissing nodig heeft, je onthoudt tot welke positie je gelezen hebt, en bij het wegschrijven controleert de store dat er sinds die positie geen nieuwe events zijn bijgekomen die aan diezelfde query voldoen. Het is exact dezelfde optimistic locking als hiervoor, alleen is de grens nu dynamisch in plaats van vastgeklonken aan één stream.

Terug naar de bestelling. We taggen het bestel-event met zowel het product als de klant. Bij het plaatsen lezen we beide soorten feiten (de voorraadmutaties van dít product én de openstaande bedragen van déze klant) en we leggen de bestelling alleen vast als aan beide regels nog voldaan is. Heeft een collega ondertussen het laatste stuk verkocht of de klant net over zijn limiet geduwd, dan faalt de append en volgt een nieuwe poging. Twee regels over twee verschillende dingen, atomair afgedwongen in één append, zonder saga en zonder tussentoestand.

Het enige wat je vooraf moet vastleggen, zijn de tags zelf. Vergeet je iets te taggen dat je later nodig hebt, dan moet je dat achteraf bijwerken. Maar een nieuwe regel over tags die al bestaan, vraagt geen herstructurering: het is gewoon een nieuwe query.

Waarom dit voor uw KMO interessant is

1. Regels over meerdere entiteiten, atomair afgedwongen

Veel echte businessregels zijn van het type "alleen als X én Y". Alleen leveren als het op voorraad is én de klant binnen zijn krediet blijft. Alleen inplannen als de monteur vrij is én de klant geen overlappende afspraak heeft. DCB dwingt zo'n regel in één controle af, in plaats van via een broze coördinatie tussen losse onderdelen.

2. Minder omwegen, dus minder code en minder bugs

Sagas en reserveringspatronen zijn veel machinerie: extra events, tussentoestanden, compensatielogica voor als het halverwege misloopt. DCB schrapt dat grotendeels. Minder code betekent minder dat stuk kan gaan, minder onderhoud en uiteindelijk minder budget, een terugkerend thema in hoe wij overengineering vermijden.

3. Nieuwe regels zonder de structuur te herzien

Omdat de grens een query is en geen vaste structuur, is een nieuwe invariant meestal gewoon een nieuwe query over bestaande tags, zonder her-streamen van je historiek. Uw software buigt mee in plaats van te breken bij elke nieuwe businessvraag.

4. Uniciteit en "exact één keer" worden triviaal

Geen twee klanten met hetzelfde klantnummer, een afspraakslot dat maar één keer geboekt raakt, geen dubbele verwerking als iemand twee keer op verzenden klikt. Klassiek zijn dat verrassend hardnekkige problemen die je vaak met een aparte reserveringstabel of read model oplost. Met DCB vallen ze samen in diezelfde ene controle: alleen vastleggen als er ondertussen niets met dat gegeven gebeurd is.

Het zit hem in je tags

DCB goed inzetten draait om één keuze: hoe smal je je grenzen trekt. Tag je een regel zo precies als hij vereist, dan krijg je sterke consistentie exact waar het telt, zonder onnodige botsingen. Trek je de grens te breed, bijvoorbeeld "alles van deze ene erg drukke klant moet altijd samen consistent zijn", dan verdringen schrijfacties elkaar en moeten ze opnieuw proberen. Doordacht tags kiezen is dus het halve werk, en precies daar zit onze ervaring.

Wie de uitgewerkte voorbeelden wil zien, vindt ze op dcb.events.

Kortom

Event sourcing geeft uw bedrijf een geheugen dat meegroeit. DCB zorgt ervoor dat de regels die over meerdere delen van dat geheugen tegelijk gaan, betrouwbaar afdwingbaar blijven, zonder de omwegen die zulke regels vroeger duur en foutgevoelig maakten.

Voor KMO's met écht samenhangende processen (voorraad, facturatie, reserveringen, een CRM-pijplijn) is het precies het gereedschap dat de scherpe randen van event sourcing wegslijpt. Voor ons is het intussen geen aparte afweging meer: doen we event sourcing, dan doen we het op deze manier.

Benieuwd of dit past bij uw project? Een vrijblijvend gesprek bij Tandem Studio kost u niets en levert minstens een helder antwoord op.