Registeranatomie

In het voorgaande is de context beschreven. Hieronder beschrijven we de elementen waaruit het register bestaat.

Contextuele elementen

In de afbeelding hierboven zien we allereerst de eerder geïntroduceerde elementen signaal, taak, gevolg en levering terug. Deze elementen zijn geïllustreerd als bedrijfsobject.

Om op basis van het ene het opvolgende bedrijfsobject te kunnen produceren (bijvoorbeeld een gevolg op basis van een taak) zijn handelingen (bijvoorbeeld taak uitvoeren) nodig. Deze werden eerder impliciet benoemd, maar worden nu expliciet als bedrijfsprocessen opgenomen.

De wijze waarop bedrijfsprocessen worden uitgevoerd is beschreven in het model van de bounded context. De inhoud hiervan is vaak gebaseerd op andere kaders, zoals wet- en regelgeving, beleid en bedrijfs- of uitvoeringsregels. Het bindende karakter van het model wordt benadrukt door de illustratie als contract.

Het register zelf is geïllustreerd als element van het type application-collaboration om aan te geven dat het register niet per se één applicatieve component hoeft te zijn, maar ook - en misschien zelfs meestal - kan bestaan uit een samenhangende verzameling applicatiecomponenten.

Van commando naar gevolg

De elementen die bijdragen aan de verwerking van commando's en productie van gevolgen op basis daarvan, vormen de bijhoudingskant ('C' in CQRS) van het register.

Het register wordt bediend door het aanbieden van commando's. Deze data-objecten volgen altijd de taal en het model van de bounded context waarbinnen ze worden gemaakt en verwerkt.

Zowel de semantische en syntactische eisen aan commando's als de wijze waarop die verwerkt moeten worden, zijn beschreven in het bijhoudingsmodel (data-object). Dit vormt dus het contract op basis waarvan commando's worden verwerkt.

De Commandoverwerkingsservice (applicatieservice) controleert of aangeboden commando's aan het contract voldoen.

Het bijhoudingsmodel en Commandoverwerkingsservice horen bij de Commandoprocessor (applicatiecomponent) die met het commando als input op basis van in het bijhoudingsmodel beschreven regels gevolgen (data-objecten) produceert.

Voor ieder bedrijfsobject van het type Gevolg dat wordt geproduceerd als resultaat van het bedrijfsproces 'Taak uitvoeren', wordt door het verwerken van een commando een equivalent data-object van het type gevolg geproduceerd. Dit data-object is een directe representatie van het bijbehorende bedrijfsobject. Zo registeren we (tenminste) de essentie van het overheidshandelen.

Gevolgen worden opgeslagen in de Gevolgenstore (applicatiecomponent).

De Gevolgenstore biedt toegang tot gevolgen via de Gevolgen-bevrageninterface (applicatie-interface). Deze interface wordt gebruikt door de Commandoprocessor als gegevens uit eerder vastgelegde gevolgen nodig zijn om te beoordelen of een commando valide is en om te bepalen welk gevolg moet worden geproduceerd.

Van gevolg naar projecties

De elementen die bijdragen aan de verwerking van gevolgen en productie van projecties op basis daarvan vormen de leveringskant ('Q' in CQRS) van het register.

Een gevolg dient als input voor de Gevolgenverwerkingsservice (applicatieservice).

De Gevolgenverwerkingsservice is onderdeel van de Gevolgenprocessor (applicatiecomponent) die projecties (data-objecten) produceert.

Projecties worden opgebouwd op basis van het leveringsmodel (data-object) dat beschrijft welke gegevens in welke vorm in een bepaalde projectie worden opgenomen.

Een projectie is een data-object, bedoeld om afnemers binnen en buiten 'onze' bounded context te informeren over wat binnen onze context is gebeurd. Een projectie kan allerlei vormen hebben: een databaserelatie, een notificatie(bericht) of een (digitaal) document.

Van het 'setje' Gevolgenverwerkingsservice, Gevolgenprocessor en leveringsmodel kunnen er meerdere naast elkaar bestaan. Dit betekent dat één gevolg door meerdere Gevolgenprocessoren wordt verwerkt om verschillende projecties op te bouwen.

Projecties kunnen 'on demand' (op aanvraag) worden gegenereerd of worden gepersisteerd. In dat laatste geval is in de vorm van een Projectiestore een extra applicatiecomponent nodig.

Toegang tot projecties wordt geleverd door de Projectietoegangsinterface(s) (applicatie-interface).

Anders dan bij de relatie tussen Gevolg (bedrijfsobject) en gevolg (dataobject), vormt de projectie (dataobject) niet de volledige representatie van de Levering (bedrijfsobject). De projectie bestaat immers direct nadat die is geproduceerd, terwijl van een Levering pas sprake is nadat de projectie of een selectie daaruit aan iets of iemand beschikbaar is gesteld. Een Levering is daarom een voor consumptie aangeboden projectie.

Bespiegeling over projectie op basis van gevolg versus gevolg volgend op eerder gevolg

Bovenstaande laat ruimte voor discussie over de vraag in welke gevallen sprake is van een projectie op basis van een gevolg en een gevolg op basis van een eerder geproduceerd gevolg. Hiernaar kunnen we op ten minste drie manieren kijken:

1. Iedere bewering die op basis van een gevolg (geautomatiseerd) binnen het register kan worden gecreëerd, beschouwen we als projectie. De binnen het register geproduceerde bewering met een 'happened', of gebeurtenisachtig karakter "aanschrijfvorm van persoon p1 gewijzigd in 'mevrouw'" op basis van gevolg "geslacht van persoon p1 gewijzigd in 'vrouw'" wordt in dit geval beschouwd als projectie.
2. We beschouwen alleen representaties van een gevolg zelf, of daarvan afgeleide stand (of state-)informatie als projecties. Vervolgbeweringen met een 'happened'-karakter beschouwen we als nieuwe gevolgen. De binnen het register geproduceerde bewering "aanschrijfvorm van persoon p1 gewijzigd in 'mevrouw'" op basis van gevolg "geslacht van persoon p1 gewijzigd in 'vrouw'" is in dit geval als nieuw gevolg. De op basis van hetzelfde gevolg geproduceerde standbewering "geslacht van p1 is 'vrouw'" beschouwen we wél als projectie.
3. We maken helemaal geen onderscheid tussen gevolgen en projecties. Iedere nieuwe bewering zien we als gevolg.

Niet geïllustreerd: van signaal naar commando

Het verwerken van signalen kan uiteraard ook applicatief ondersteund en eventueel geautomatiseerd worden. Dit geldt zeker als een signaal in de vorm van een notificatie wordt ontvangen. Omdat zo'n notificatie (ten opzichte van het register) veelal van buiten de 'eigen' bounded context afkomstig is, en vanuit het register dus geen controle bestaat over de vorm en inhoud daarvan, beschouwen we de elementen in de applicatiearchitectuur die hiervoor nodig zijn niet als onderdeel van het register. Deze elementen zijn daarom hierboven niet geïllustreerd. Wel verdient dit expliciete aandacht, zoals ook beschreven bij contextovergangen.