Van event sourcing naar betrouwbaar register

Je herkent de terminologie meteen. Een gevolgenjournaal – dat klinkt als een event store. Gevolgen vastleggen – dat is event sourcing. Projecties afleiden uit die gevolgen – dat zijn read models. Commando's verwerken – CQRS. Bounded contexts afbakenen – DDD.

De handreiking betrouwbare registers noemt DDD, CQRS en event sourcing ook expliciet als inspiratiebronnen (zie Achtergronden: Inspiratie). De patronen die in de jaren 2000–2010 zijn ontwikkeld in de domeingestuurde software-architectuur bieden een vocabulaire dat nuttig is om over registers te praten. De handreiking bouwt er dankbaar op voort.

Maar er is een valkuil. Als je sterk in event sourcing en CQRS thuis bent, is de verleiding groot om de handreiking te lezen als "event sourcing maar dan voor de overheid" – een vertrouwde aanpak met een paar overheidsspecifieke toevoegingen. Die lezing is begrijpelijk, maar mist iets wezenlijks.

Naast de vertrouwde toestand-opslag verschijnt een append-only journaal: precies je event store, hier Effects genoemd. Tot zover herken je alles.

Het verschil zit in wat er in dat journaal komt te staan. Een event in een reguliere event-sourced applicatie beschrijft een feit in het domeinmodel: iets is gebeurd, de applicatie reageert. Een gevolg draagt zijn hele herkomst met zich mee – niet alleen wát is vastgesteld, maar door wie, op basis van welke legitimering, en volgens welke werkwijze. De keten loopt van wet & beleid en een zaak, via een commando, tot het antwoord dat een afnemer uiteindelijk ontvangt. Dat is het performatieve karakter dat verderop terugkomt: het optekenen van een gevolg is geen intern feit in een domeinmodel, maar een institutionele handeling.

Aan de leeskant herken je een vertrouwd patroon: de Store levert niet één centrale tabel, maar afgeleide projecties – het read-model-idee uit CQRS. Het verschil is dat een projectie in de handreiking een eigen verantwoordelijkheid draagt. Ze weet niet alleen wát ze levert, maar ook hoe zeker die informatie is en op basis van welke vastlegging ze tot stand kwam – metagegevens die een gewoon read model niet hoeft bij te houden.

En de geschiedenis die dat journaal opbouwt, is niet alleen chronologisch. Een event store legt vast wanneer iets is vastgelegd – het systeemtijdstip. Een register moet daarnaast kunnen zeggen wat er geldig was in de werkelijkheid, los van wanneer dat is vastgelegd – het geldigheidstijdstip. Beide tijdassen blijven zichtbaar, ook na een correctie. Meer over hoe die twee tijdassen in projecties werken: de verdieping temporaliteit in projecties.

Corrigeren gaat via diezelfde route. Een terugmelding doorloopt dezelfde Capture-route als elk ander bericht, leidt tot een onderzoek, en dat onderzoek raakt zowel de betrokken projectie als het journaal – om uiteindelijk, als het onderzoek daartoe aanleiding geeft, een nieuw commando te worden: een correctie. Niets wordt overschreven of teruggedraaid; er komt een nieuw, herleidbaar gevolg bij.

Niet de techniek maar deze verantwoordelijkheid – rechtsgeldig vaststellen, niet alleen intern registreren – bepaalt hoe gevolgen, projecties, correcties en bounded contexts in de handreiking zijn ontworpen. Dit verhaal loopt de vijf meest voorkomende "valse herkenningen" langs. Niet om event sourcing te bekritiseren, maar om duidelijk te maken waar het model van de handreiking verdere eisen stelt – eisen die voortvloeien uit de institutionele aard van overheidsregistratie.

"Gevolg is toch gewoon een event?"

Ja – in de technische zin klopt dat: een gevolg is een event zoals event sourcing dat kent. Het wordt vastgelegd naar aanleiding van iets wat is gebeurd, is immutable en vormt de basis voor projecties. Maar de omkering geldt niet: niet elk event is een gevolg.

De handreiking trekt die grens scherp. Een gevolg is niet zomaar een toestandsverandering, maar het "duurzaam betekenisvol resultaat van overheidshandelen" – het resultaat dat in de meest directe zin antwoord geeft op de aanleiding voor of vraag om dat handelen (zie hoofdstuk 4). Een tussenstap, een interne afweging of een technisch detail zonder zelfstandige betekenis voor de uitvoering van de taak, is geen gevolg – ook al zou je het in een gewoon event-sourced systeem prima als event kunnen vastleggen.

Wat een event tot gevolg maakt, is dus niet de vorm, maar de betekenis. Het optekenen van een gevolg in een overheidsregister vestigt niet alleen een feit in een applicatiemodel – het constitueert een institutioneel feit. De overheid stelt daarmee vast dat iets het geval is, en dat vestigen heeft rechtsgevolgen die losstaan van de technische implementatie. Dat is het performatieve karakter van een gevolg.

Dit heeft concrete implicaties. Een gevolg bevat niet alleen wat er is vastgesteld, maar ook wie het heeft vastgesteld, op basis van welke legitimering en op welk moment. Die informatie is geen optionele metadata maar kern van de vastlegging.

Meer over de aard van gevolgen: hoofdstuk 4 (uitvoeringscontext) en hoofdstuk 6 (conceptueel registermodel).

"Projecties zijn read models – op te bouwen en weg te gooien"

In event sourcing zijn read models afleidingen: op elk moment opnieuw op te bouwen vanuit de event store, en dus net zo makkelijk weg te gooien. Zolang de event store intact is, blijft het read model reproduceerbaar. Het heeft geen eigen verantwoordelijkheid die verder reikt dan de applicatie.

In de handreiking zijn projecties ook reproduceerbaar, maar dat betekent niet dat ze zomaar weg te gooien zijn: ze hebben wél een eigen verantwoordelijkheid. Een projectie heeft eigen metagegevens: de zekerheid van de verstrekte informatie (onderschreven, in onderzoek of betwist), de onderschrijvende instantie en een verstrekkersreferentie – een sleutel die maakt dat altijd kan worden gereconstrueerd op basis van welke projectietoestand een afnemer is bediend.

Die verstrekkersreferentie is de basis voor terugmeldingen: een afnemer die twijfelt aan een ontvangen gegeven, kan die twijfel terugkoppelen, en het register kan nagaan welke projectietoestand de afnemer destijds ontving. Dat is niet mogelijk als een projectie een vrijblijvende view zonder eigen verantwoordelijkheid is.

Meer over projecties: hoofdstuk 6 en hoofdstuk 9 (verdieping projecties). De technische uitwerking van de bitemporele opslag van payloads in projecties staat in de verdieping over de bitemporele payloadstore.

"Bounded context = microservice-grens"

In DDD definieert een bounded context een afgebakend semantisch domein met eigen taal. In de praktijk worden bounded contexts vaak gelijkgesteld aan microservices of aparte diensten. Dat is begrijpelijk – de operationele vraag "hoe zetten we dit uiteen?" neigt ernaar de semantische grenzen te volgen of zelfs te overschrijven.

In de handreiking is een bounded context primair een semantisch concept. De grens wordt bepaald door taal en betekenis, niet door de operationele inrichting. Dat is conform DDD – maar de handreiking voegt een cruciale praktische dimensie toe: contextovergangen vereisen expliciete vertaling.

Als een gegeven de grens overschrijdt van de ene naar de andere context, moet die overgang worden gedocumenteerd. De handreiking beschrijft hoe: elk contextovergangspunt heeft een eigen verantwoordelijkheid voor de vertaling, en die vertaling is onderdeel van de vastlegging. Zo is altijd herleidbaar hoe informatie van de ene naar de andere context is gebracht – en wie daarvoor verantwoordelijk was.

In de praktijk is de contextovergang zichtbaar in de WOZ-casus: de BRK spreekt van tenaamstellingen, het WOZ-domein van belangen. Het voorbeeld belang overgegaan naar aanleiding van eigendomsoverdracht laat zien hoe die vertaling expliciet is belegd, niet impliciet verborgen in een mapping.

Meer: hoofdstuk 3 (grenzen) en hoofdstuk 6.

"Compensating events lossen correctie op"

In event sourcing worden correcties soms verwerkt als compensating events: je kunt een eerder event niet terugdraaien, dus je voegt een event toe dat het effect opheft. Dat is technisch elegant voor event-sourced systemen die alleen systeemtijdstip kennen.

In de handreiking is een correctie rijker dan een compensating event, omdat het register (minstens) twee tijdassen bijhoudt. Een correctie in de handreiking is een nieuw gevolg dat: het te corrigeren gevolg bij naam (of id) noemt (audittrail van de correctie zelf), het geldigheidstijdstip specificeert waarop de correctie betrekking heeft (domeintijd), en de oorspronkelijke vastlegging intact laat (systeemtijdstip).

Een compensating event heft een effect op in de applicatielogica. Een correctie in de handreiking documenteert wat er werkelijk het geval was – en laat zien dat het register eerder iets anders stelde. Beide tijdassen blijven zichtbaar in het eindresultaat: de foutieve periode is verantwoordbaar, niet ongedaan gemaakt.

Dit verschil is cruciaal voor registers die juridisch verantwoording moeten afleggen over wat ze verstrekt hebben.

Meer: hoofdstuk 6, hoofdstuk 8 (verdieping gevolgenjournaal) en de verdieping correctie van gevolgen.

"CQRS is een technisch optimalisatiepatroon"

CQRS – de scheiding van schrijven en lezen – wordt vaak beschouwd als een architectuur en daarmee technische keuze voor systemen met sterk uiteenlopende lees- en schrijfbelasting, of wanneer read modellen onafhankelijk moeten kunnen schalen. De impliciete boodschap is: gebruik het als je er een reden voor hebt, anders is het overkill.

In de handreiking is de scheiding van bijhouding en verstrekking niet primair een technische keuze maar een principiële. De motivatie komt uit de epistemische nederigheid die de handreiking als vertrekpunt neemt: wat het register weet en wat het verstrekt, zijn twee verschillende verantwoordelijkheden. De bijhouding documenteert wat er is vastgesteld en hoe. De verstrekking biedt informatieproducten aan afnemers, met expliciete zekerheidsmarkeringen en verstrekkersreferenties.

Die scheiding is niet bedoeld om het systeem schaalbaarder te maken, maar om de verantwoordelijkheid voor verstrekking expliciet te houden. Een afnemer krijgt niet "de database" maar een informatieproduct dat te verantwoorden is naar zijn inhoud, herkomst en zekerheid.

Meer over waarom de scheiding principieel is: hoofdstuk 1 (aanleiding en doel) en hoofdstuk 5 (datalaag).

Aanbevolen leesroute

Begin met hoofdstuk 1 (aanleiding en doel) voor de epistemische motivatie achter het model. Lees daarna hoofdstuk 4 (uitvoeringscontext) voor de institutionele aard van gevolgen. Hoofdstuk 6 (conceptueel registermodel) beschrijft de kern van de architectuur. Hoofdstuk 3 (grenzen) legt uit hoe contextovergangen werken.

De vergelijking van de handreiking met de concepten die haar hebben gevoed staat in Achtergronden: Inspiratie, met uitgewerkte beschrijvingen van event sourcing, CQRS en domain-driven design.

De casus BRP laat de rijkdom van gevolgen zien: adoptie als een gevolg dat tegelijk meerdere facetten van een persoonssituatie wijzigt, met expliciete legitimering en contextovergang.