Copyright © 2026 VNG Realisatie. Dit werk is gelicenseerd onder een Creative Commons Naamsvermelding 4.0 Internationaal-licentie (CC BY 4.0).

Aanleiding en doel

Waar ontbreekt het (nu) aan?

De overheid heeft de bevoegdheid om vergaand in de situatie van burgers en bedrijven in te grijpen. Door automatisering van het inwinnen en verwerken van gegevens kon dit ingrijpen een steeds grootschaliger karakter krijgen. Onze vermogens om overheidshandelen te begrijpen, controleren en daarbij eventueel gemaakte fouten te herstellen hielden met de mogelijkheden van digitalisering echter geen gelijke tred.

Waar het misging werden daardoor niet alleen meer burgers en bedrijven getroffen. Doordat gegevens geautomatiseerd door ketens stroomden, konden op basis daarvan meerdere organisaties handelen. Fouten hadden daardoor voor betrokkenen ook verstrekkender gevolgen.

Deze handreiking beschrijft hoe we overheidsinformatie in registers zodanig kunnen vastleggen en beschikbaar stellen dat we de betekenis en waarde daarvan beter kunnen beoordelen, fouten zoveel mogelijk kunnen voorkomen en die - als dat niet lukt - in ieder geval herstellen.

De happy en de crappy flow

Zo lang burgers en bedrijven dingen willen die wij vooraf hadden bedacht, tijdig de juiste informatie aanleveren, en ‘onze’ overheidsgegevens kloppen - voorwaarden waaraan in de meeste gevallen wordt voldaan - verlopen processen snel en met minimale menselijke tussenkomst.

Maar wat gebeurt er als zo’n burger of bedrijf wordt geconfronteerd met een situatie die niet past binnen de grenzen van de happy flow? Bijvoorbeeld naar aanleiding van een minder vaak voorkomend verzoek of betrokkenheid bij een proces met onvoorspelbaar verloop. Nog lastiger wordt het als iets moet worden aangevochten, onderzocht of gecorrigeerd? Deze handelingen zijn onderdeel van de crappy flow: een werkstroom die vrijwel altijd handwerk vereist, en soms überhaupt niet wordt afgehandeld.

Dit betekent dat resultaten die ontstaan uit happy flows zich gemakkelijk en grotendeels geautomatiseerd door het overheidsapparaat kunnen verspreiden, terwijl uit crappy flows voortkomende twijfelindicaties en correctiehandelingen - als ze al verwerkt worden - nauwelijks de grens oversteken naar vanuit gegevensgebruikperspectief stroomafwaarts liggende domeinen. Waardoor in die domeinen op basis van verkeerde gegevens onjuiste gevolgen geproduceerd kunnen worden.

Parabel: Infrastructuur van Digitalië

De eilanden van het atollenrijk Digitalië zijn met indrukwekkende hogesnelheidsinfrastructuur verbonden. Maar die is alleen toegankelijk voor een selecte meerderheid van contente conformisten.

Pogingen om op deze infrastructuur ook een minderheid van abusievelijke anarchisten toe te laten zijn allemaal mislukt. Want deze groep zonder vaste bestemming negeerde zorgvuldig vastgestelde gewichts- en hoogtebeperkingen, bewoog zich tegen rijrichtingen in en vroeg om afritten op onmogelijke plaatsen.

Terwijl hoog boven de golven contente conformisten voortrazen, zijn abusievelijke anarchisten in hun kleine scheepjes nog altijd overgeleverd aan de stormen van de Analoge zee. “Natuurlijk is dat onrechtvaardig”, bevestigt een beleidsmaker. “Maar er is gewoon geen businesscase.”

Epistemische nederigheid

Het bovenstaande maakt duidelijk dat overheidsinformatie niet altijd klopt. En dit soort onjuistheden zullen altijd overblijven, hoeveel crappy flows we ook in happy flows weten om te zetten. Deze constatering vraagt om epistemische nederigheid; het erkennen dat onze kennis beperkt, voorlopig en mogelijk onjuist is.

Maar naar dit principe handelen is moeilijk als het gereedschap om de waarde van informatie te kunnen beoordelen ontbreekt. Binnen de overheid kunnen we zo’n inschatting op dit moment vaak alleen voor het ‘eigen’ domein maken. Dit betekent dat we niet kunnen achterhalen wie een keten van overheidshandelen in beweging heeft gezet, en wanneer en met welke reden dat is gebeurd. En dat we geen compleet beeld hebben van hoe lang óns handelen verderop in de keten nog doorwerkt.

Om dit op te lossen hebben we meer en beter inzicht in de context van onze informatie nodig. Deze behoefte kunnen we samenvatten in een aantal aspecten:

• Bron: welke input was de basis ons handelen?
• Legitimering: welke wet of regel legitimeerde ons handelen en het gevolg dat door dat handelen werd geproduceerd?
• Verantwoordelijke: wie was verantwoordelijk voor ons handelen?
• Werkwijze: welke (geautomatiseerde) handelingen hebben we uitgevoerd om een gevolg te produceren?
• Zekerheid: in hoeverre, en op grond waarvan kunnen we uitgaan van de (on)juistheid van een gegeven?
• Historie: hoe zag de situatie er in het verleden uit en welke veranderingen hebben door de tijd heen plaatsgevonden?

Wat is een register?

Betekenis van het begrip ‘register’

Het woord ‘register’ heeft in verschillende contexten uiteenlopende bekentenissen. Een organist zal daarbij denken aan een serie orgelpijpen met dezelfde klankkleur, een auteur ziet een lijst met trefwoorden voor zich, terwijl een werkplekbeheerder zich de editor voorstelt waarmee instellingen van Windowssystemen kunnen worden aangepast.

Associaties van geïnteresseerden in deze handreiking zullen waarschijnlijk dichter bij elkaar liggen. Maar ook als we de betekenisruimte inperken door te stellen dat een register iets te maken moet hebben met het verwerken van informatie binnen de overheid, blijven nog uiteenlopende zienswijzen over. Bijvoorbeeld:

• holistisch: een volledig stelsel gericht op het bijhouden en leveren van bepaalde gegevens, bestaande uit wet- en regelgeving, betrokken organisaties en hun onderlinge afspraken, systemen voor opslag en distributie van gegevens en de technische infrastructuur die hiervoor nodig is;
• universeel: een digitaal of fysiek bijgehouden verzameling geordende informatie;
• afnamegericht: een plaats waar bepaalde gegevens onder bepaalde voorwaarden verkregen kunnen worden, of
• technisch: een database.

Om verwarring te voorkomen, is het belangrijk het begrip register in de context van ‘Uit betrouwbare bron’ betekenis te geven. Wij definiëren een register als volgt:

“Een applicatiecomponent, of een verzameling samenwerkende applicatiecomponenten, gericht op het betrouwbaar vastleggen en presenteren van een geordende verzameling digitale overheidsinformatie.”

Register of registratie?

Binnen de overheid gebruiken we voor aanduiding van een georganiseerde gegevensverzameling zowel het begrip register (Kentekenregister, Register van overheidsorganisaties, BIG-register, UBO-register) als registratie (met name in de context van basisregistraties).

Er zijn twee redenen om binnen ‘Uit betrouwbare bron’ het begrip register te gebruiken. Enerzijds sluit dat het beste aan bij de betekenis in ‘gewoon’ taalgebruik. Een register is volgens het Van Dale-woordenboek een “inschrijvingsboek, naamlijst; goed geordende inhoudsopgave: bevolkingsregister, namenregister”, terwijl registratie wordt gedefinieerd als “inschrijving in een register: de registratie van een koopakte.”

Daarnaast willen we de indruk vermijden dat ‘Uit betrouwbare bron’ gaat over basisregistraties. Hoewel het project niet tot doel heeft een in productieomstandigheden werkend register op te leveren, verwachten we dat in deze handreiking beschreven bevindingen in eerste instantie waardevol zullen zijn binnen domeinen waarbinnen op basis van gedeelde kennis intensief wordt samenwerkt, maar (nog) geen basisregistratie bestaat.

Perspectieven op het register

Een definitie alleen is niet genoeg om duidelijk te maken waarover ‘Uit betrouwbare bron’ gaat. Ook een applicatiecomponent kan je immers vanuit verschillende perspectieven benaderen. Om duidelijk te maken welke daarvan wij innemen, beschrijven we de scope van het project aan de hand van twee elkaar aanvullende architectuurmodellen:

1. De European Interoperability Reference Architecture (EIRA)
2. Het Common Ground-vijflagenmodel

Architectuurlagen en scope UBB

Betere ondersteuning van de crappy flow en het faciliteren van epistemische nederigheid vereist verandering in alle EIRA-lagen: juridisch, organisatorisch en technisch. Deze handreiking richt zich echter primair op de semantische en applicatielaag (het gebied binnen de paarse gestreepte lijn in bovenstaande figuur).

Binnen de applicatielaag kunnen we dankzij het Common Groundmodel preciezer zijn over onze scope: we beperken ons tot de lagen ‘databronnen’, ‘diensten’ en vanwege de relatie tussen bijhoudingsdiensten en processen die deze gebruiken ook een deel van ‘procesinrichting’ (gele gestreepte lijn in bovenstaande figuur). Dit betekent dat we bijvoorbeeld aanbevelingen doen voor:

• welke concepten belangrijk zijn om de werking van het register te begrijpen, welke betekenis we daaraan geven en hoe de samenhang daartussen eruit ziet;
• uit welke conceptuele ‘bouwblokken’ het register bestaat en welke rol die spelen;
• welke generieke (dus onafhankelijk van welke gegevens een register omvat toepasbare) functionaliteit het register moet leveren, en
• hoe deze functionaliteit met behulp van API’s toegankelijk te maken.

Hoewel we andere lagen niet helemaal kunnen en willen negeren - hieronder bespreken we bijvoorbeeld de begrenzing van het register in relatie tot de (organisatorische) domeinen die het ondersteunt - betekent deze scopeafbakening dat we in deze handreiking geen aanbevelingen doen over bijvoorbeeld:

• interpretatie of herziening van wet- en regelgeving;
• verdeling van verantwoordelijkheden over organisaties (wel/niet gescheiden organisaties voor bijhouding en verstrekking, bijhouding en verstrekking wel/niet organisatorisch federatief of juist centraal);
• gebruik van specifieke technische producten (hoewel die bij onze beproevingen wel een belangrijke rol spelen);
• bij concrete implementatie in één technisch product clusteren van applicatiecomponenten (bijvoorbeeld vanwege van efficiëntie- of performanceredenen), en
• het ontwerpen van interfaces om registergegevens aan gebruikers te presenteren.

De overheid verkaveld

Registers staan niet op zichzelf, maar ondersteunen de overheid bij het invullen van haar administratieve behoeften. Die overheid vormt geen homogeen, eenduidig handelend geheel, maar is een pluriform en complex systeem.

Om de verhouding tussen register en overheid te kunnen duiden, moeten we dat systeem - liefst op basis van objectieve criteria - kunnen verkavelen naar logisch samenhangende delen, zonder daarbij al te veel door bestaande indelingen geleid of gehinderd te worden.

Ons streven is dat ieder van die delen groot genoeg is om zelfstandig bestaansrecht te hebben, maar klein genoeg om een ondubbelzinnig begrip van concepten, regels en processen te kunnen waarborgen.

Domein

Vaak wordt het woord domein gebruikt om binnen het totaal aan taken en verantwoordelijkheden van de overheid een specifiek, samenhangend werkgebied aan te wijzen. Maar anders dan in de wiskunde kent het begrip domein in organisatorische context geen objectieve afbakeningscriteria. Dit blijkt bijvoorbeeld uit de definitie die Eric Evans hanteert in de context van Domain-driven design. Evans beschouwt een domein als “een sfeer van kennis, invloed of activiteit”. Hoewel deze definitie een zekere mate van interne samenhang veronderstelt, sluit die niet uit dat binnen één domein:

• dezelfde concepten verschillend geïnterpreteerd worden,
• regels en gedrag niet consistent zijn, en
• bedrijfsprocessen niet op elkaar zijn afgestemd.

Een domein voldoet dus weliswaar aan de eis van zelfstandig bestaansrecht, maar is niet restrictief genoeg om ondubbelzinnig begrip van wat daarbinnen gebeurt te waarborgen.

Bounded context

Binnen een domein kunnen meerdere subdomeinen of taakgebieden bestaan. Daarbij horen verantwoordelijkheden, die zijn toegekend aan specifieke teams, afdelingen of bedrijfseenheden. Zij worden ondersteund door eigen semantiek, processen en regels. Deze zaken kunnen worden beschreven in een model: een systeem van abstracties dat beschrijft hoe men vanuit een taakgebied naar de wereld kijkt en reageert op veranderingen in de buitenwereld. Zo’n model is beschreven in gemeenschappelijke taal die binnen het hele taakgebied begrepen wordt.

Model en taal beschrijven dus een voor betrokkenen herkenbare ‘blauwdruk’ van het taakgebied, die (onder andere) de basis kan vormen voor het ontwerp van een register. Een in gemeenschappelijke taal ondubbelzinnig en samenhangend gemodelleerd taakgebied noemen we een bounded context.

Het belang van het erkennen van bounded contexten wordt door Eric Evans in ‘the Blue Book’ over Domain driven design als volgt beschreven:

“A bounded context delimits the applicability of a particular model so that team members have a clear and shared understanding of what has to be consistent and how it relates to other contexts. Within that context, work to keep the model logically unified, but do not worry about applicability outside those bounds. In other contexts, other models apply, with differences in terminology, in concepts and rules, and in dialects of the ubiquitous language [red. gemeenschappelijke taal]. By drawing an explicit boundary, you can keep the model pure, and therefore potent, where it is applicable. At the same time, you avoid confusion when shifting your attention to other contexts. Integration across the boundaries necessarily will involve some translation, which you can analyze explicitly.”

Uit dit citaat blijkt dat de ambiguïteiten die we op domeinniveau nog konden tegenkomen binnen een bounded context (idealiter) verdwijnen. Hier geldt (zoveel mogelijk) dat:

• dezelfde concepten eenduidig geïnterpreteerd worden (op basis van gemeenschappelijke taal),
• regels en gedrag consistent zijn, en
• bedrijfsprocessen op elkaar aansluiten.

Contextovergangen

Bounded contexten bestaan zelden in volledige isolatie. Veel vaker zijn ze in ketens of netwerken verbonden met andere bounded contexten. Dit betekent dat een gevolg dat werd geproduceerd in de ene context, in een volgende context wordt beschouwd als aanleiding of trigger voor het produceren van een nieuw gevolg. Bij het oversteken van de grens tussen de twee bounded contexten ontstaat een contextovergang. Hierbij moeten taal en model van de ene context omgezet worden naar taal en model van de andere.

Verstrekkingen kennen daarom geen ‘vaste’ bounded context. Deze kunnen zijn opgesteld in de taal van de context die het gevolg produceerde waarover een verstrekking gaat. In andere gevallen kan een verstrekking echter expliciet bedoeld zijn om een specifieke (afnemende) bounded context te informeren. Op verzoek van deze contexten kunnen vanuit de producerende context daarom verstrekkingen worden geproduceerd die dichter tegen de context van de ‘afnemende bounded context’ aanliggen.

Afhankelijk van de situatie zal een producent van gevolgen ervoor kiezen om beide te doen: naast één of meerdere verstrekkingen die taal en model van de ‘eigen’ context volgen, worden dan óók verstrekkingen gemaakt die aansluiten bij de conventies van bounded contexten van afnemers.

Taak en gevolg hebben wel een vast bounded context en conformeren zich altijd aan de taal en het model van de bounded context waarbinnen ze worden uitgevoerd c.q. geproduceerd.

Voor meer informatie zie de Verdieping: Bounded Context Bridge en voorbeeld belang overgegaan naar aanleiding van eigendomsoverdracht.

Uitvoeringscontext van registers

Binnen iedere bounded context wordt gewerkt. Een deel van dat werk slaat neer in onze registers. Om te begrijpen welk deel, moeten we het karakter van dit werk op abstract niveau begrijpen. In dit hoofdstuk beschrijven we daarom een conceptualisering van de overheid als uitvoerder van taken die horen bij publieke dienstverlening. Vertrekt hiervoor is de overheid als producent van gevolgen en consument van verstrekkingen.

De overheid als producent van gevolgen

Het begrip gevolg wordt op Wikipedia beschreven als “een gebeurtenis of omstandigheid die optreedt als resultaat van een of meer oorzaken en bijdragende factoren en omstandigheden”. Binnen de context van deze handreiking hanteren we een wat preciezere betekenis, namelijk het gevolg als “duurzaam betekenisvol resultaat van overheidshandelen”.

Om bovenstaande definitie te begrijpen, is het behulpzaam het handelen van de overheid nader te bekijken. Dat handelen begint bij een taak of bevoegdheid, die ontstaat vanwege attributie (‘toewijzen’) door de wetgever. Artikel 5.8 van de Omgevingswet attribueert bijvoorbeeld aan het college van burgemeester en wethouders de bevoegdheid te beslissen of een omgevingsvergunning al dan niet wordt verleend.

Een bevoegdheid houdt (mits aan een aantal basisvoorwaarden voldaan is) een plicht tot handelen in; het college kan er dus niet zelfstandig voor kiezen de ene aanvraag wel, en de andere niet in behandeling te nemen. Dit betekent dat een aanvraag altijd leidt tot één of meer handelingen, die weer één of meer resultaten opleveren. In het geval van de omgevingsvergunning is aan te denken aan handelingen als:

• beoordelen op indieningsvereisten (juistheid en compleetheid)
• inwinnen advies bij ketenpartner
• besluiten over verlenen vergunning

Daarbij horen resultaten als:

• aanvraag is in behandeling genomen
• advies ingewonnen
• vergunning verleend (of niet verleend)

Niet al deze resultaten zijn echter een gevolg. We hebben immers gesteld dat daarvoor een duurzaam betekenisvol karakter nodig is. Het is niet eenvoudig deze karakteristiek in algemeenheid waterdicht te definiëren. Informeel kunnen we stellen dat het resultaat dat in meest directe zin de aanleiding voor of vraag om het overheidshandelen beantwoordt als gevolg gezien moet worden. Vaak (maar niet per definitie) is zo’n gevolg gelijk aan het rechtsgevolg dat naar aanleiding van overheidshandelen ontstaat.

In het geval van de omgevingsvergunningaanvraag beschouwen we op basis hiervan het verlenen (of juist het niet verlenen) van de gevraagde omgevingsvergunning als gevolg. Specifieke voorwaarden waaronder de vergunning is verleend, zoals een maximaal bouwvolume of vereiste goothoogte kunnen van zo’n gevolg onderdeel zijn.

Hoewel het voor de hand ligt een gevolg te beschouwen als verandering in de bounded context waarbinnen gehandeld wordt, maakt het bovenstaande duidelijk dat hiervan niet altijd sprake hoeft te zijn. Het niet-verlenen van de omgevingsvergunning betekent vanwege het gesloten karakter van het omgevingsrecht dat iets wat vóór de aanvraag niet mocht, nu nog steeds niet mag. Hier is dus sprake van een (beargumenteerde) bevestiging van de bestaande situatie, en niet van een verandering. Zo’n verandering zien we wel als de vergunning wordt verleend, waarna iets wat eerst niet mocht, (nu) wel mag.

Productie van een gevolg

Voor een vollediger begrip van hoe een gevolg ontstaat, moeten we het bijbehorende productieproces in meer detail bekijken. Binnen dat proces kunnen we drie belangrijke concepten onderscheiden. Hierbij geldt dat ieder volgend concept afhankelijk is van het voorgaande:

1. Signaal: een indicatie dat er ergens - in de buitenwereld, een andere of de eigen overheidsorganisatie - iets is gebeurd wat aandacht verdient.
2. Taak: de handelingen die naar aanleiding van een signaal moeten worden uitgevoerd.
3. Gevolg: een duurzaam betekenisvol resultaat van overheidshandelen.

De overheid als consument van verstrekkingen

Hierboven benoemden we het signaal als aanleiding voor de productie van één of meerdere gevolgen. Maar we beschreven niet waar zo’n signaal vandaan komt. Omdat binnen de overheid vaak in ketens of netwerken wordt gewerkt, is de bron van zo’n signaal heel vaak óók de overheid. Meer precies een andere bounded context die een gevolg heeft geproduceerd en keten- of netwerkpartners daarover informeert.

Dit betekent dat de productie van een gevolg in heel veel gevallen niet het eindstation van overheidshandelen is. Vrijwel altijd willen we daarover ook anderen informeren - bijvoorbeeld de burger die een omgevingsvergunning heeft aangevraagd uit het voorbeeld hierboven, maar ook bedrijven, partnerorganisaties of collega-overheden. Deze doelgroepen hebben uiteenlopende informatiebehoeften en verwerken informatie op verschillende manieren.

Diversiteit in behoeften en verwerkingsvoorkeuren betekenen dat een informering meer omvat dan alleen de betekenis die een gevolg beschrijft. Die betekenis wordt in een bepaalde vorm overgebracht - denk aan een per mail verzonden besluit in Pdf-formaat, het resultaat van een specifieke query of een voor geautomatiseerde verwerking geschikte notificatie. Dit betekent dat we te maken hebben met een representatie van een gevolg.

Bij die representaties horen verschillende verstrekkingspatronen. Sommige verstrekkingen vinden plaats op verzoek, bijvoorbeeld na aanroep van een bevragingen-interface (API). Andere verstrekkingen worden juist proactief aangeboden, zoals een systeemnotificatie die naar aanleiding van registratie van een nieuw gevolg automatisch wordt verzonden.

Dat we met het doel anderen daarover te informeren op basis van een gevolg verschillende representaties creëren, rechtvaardigt het toevoegen van een vierde vierde begrip aan de drie concepten die we hierboven opsomden:

4. Verstrekking: een voor consumptie aangeboden doel(groep)specifieke communicatie-uiting over een gevolg.

Met de toevoeging van verstrekking (hieronder geïllustreerd als levering) is onze conceptualisatie van overheidshandelen bij publieke dienstverlening in de uitvoering compleet. Hieronder is dit proces volledig geïllustreerd.

Voorwaarden voor succesvol consumeren

Dat overheden elkaars verstrekkingen gebruiken als grondstof voor het produceren van nieuwe - eigen - gevolgen klinkt vanzelfsprekend, maar brengt voor zo’n verstrekking wel eisen met zich mee.

Een verstrekkingsconsument heeft bijvoorbeeld duidelijkheid nodig over de bedoeling en betekenis van zo’n verstrekking, zodat bepaald kan worden of de eigen taken of bevoegdheden het nodig maken naar aanleiding daarvan te handelen. Dit betekent dat bij verstrekkingen verschillende aspecten van interpreteerbaarheid een rol kunnen spelen: wat is de boodschap, op welk moment heeft die betekenis, voor wie is die bedoeld, en in welke omstandigheden is die toepasbaar? Dit noemen we de context van de verstrekking.

Producenten van verstrekkingen kunnen interpretatieverwarring over verstrekkingen deels voorkomen door die te laten aansluiten bij taal en model van consumerende bounded contexten waarbinnen gegevens ontvangen en verwerkt gaan worden.

Onderdeel van deze contextinformatie is ook twijfel over de juistheid van, of andere kwaliteitsvoorbehouden bij de inhoud van de verstrekking. Zulke twijfels kunnen zijn ontstaan na constatering van (vermoedelijke) fouten door een verstrekkingsconsument. Die moet dergelijke fouten dan wel kunnen melden, wat vraagt om betwistbare verstrekkingen - of met andere woorden: verstrekkingen waarop teruggemeld kan worden, waarop onderzoek, en indien nodig, correcties kunnen volgen.

verstrekkingen moeten daarnaast een onveranderlijk karakter hebben. Het vandaag opvragen van geleverde gegevens moet ook morgen of over een aantal jaar - zolang tenminste dezelfde vraag gesteld wordt - hetzelfde resultaat opleveren. Dit noemen we de herhaalbare vraag.

Toegangsbeperkingen zijn een laatste punt van aandacht. Bijvoorbeeld vanwege het waarborgen van de privacy van betrokkenen mogen sommige afnemers misschien niet kennisnemen van een volledig gevolg - zoals een adoptie - terwijl onderdelen daarvan - zoals een verandering van ouderschap - voor hen wel relevant zijn.

Bespiegeling over de modellering van gevolgen

Bovenstaande roept vragen op over wat nu precies de omvang en granulariteit van gevolgen bepaalt. Hierboven noemden we als uitgangspunt het (handelings)resultaat dat in meest directe zin de aanleiding voor of vraag om het overheidshandelen beantwoordt. Dit impliceert dat alléén vanuit het proces dat ze produceert wordt bepaald wat als gevolg wordt beschouwd. Als vervolgens echter blijkt dat afnemers in heel veel gevallen slechts recht hebben een deel van een gevolg in te zien - zoals in het adoptievoorbeeld - is de vraag gerechtvaardigd of voor dat gevolg niet een te grote omvang is gekozen. De metafoor van de januskop helpt hier ook: het gedeelde brein, waarin de belangen van gevolgenproducent en verstrekkingsconsument samenkomen, moet zorgen voor een logische begrenzing van het gevolg.

De ‘datalaag’ van de overheid

Nu we een beeld hebben van hoe publieke dienstverlening binnen de overheid werkt en beschikken over een bijbehorend begrippenkader, kunnen we overstappen naar het onderwerp van deze handreiking: registers. We beginnen die gezamenlijk te beschouwen, als ‘datalaag van de overheid’.

Tekortkomingen van bestaande registers

Bestaande overheidsregisters zijn op basis van ondertussen vaak decennia-oude techniek en inzichten primair ontworpen om administratieve processen efficiënter te maken. Deze inzichten en techniek zijn verrassend veerkrachtig en toekomstbestendig gebleken. Maar dit vereiste ook dat bijvoorbeeld bijhouding en verstrekking in één model werden samengebracht.

Dit compromis blijkt terugblikkend ongemakkelijk. Registers bevatten daardoor presentaties die niet helemaal voldoen aan de behoeften van afnemers, maar tegelijkertijd vanuit bijhoudingsperspectief ook niet de essentie - ofwel gevolgen representeren.

Veel registers bedienen alle afnemers op basis van één generieke gegevensset. Omdat in dat geval geen onderscheid wordt gemaakt naar taken en bevoegdheden, krijgen sommige afnemers meer informatie dan nodig - en soms zelfs toegestaan - is, terwijl anderen juist gegevens missen.

In veel registers wordt bovendien contextinformatie niet (volledig) vastgelegd. Informatie over de aanleiding van een wijziging, de juridische grondslag of de handelingen die tot het resultaat hebben geleid ontbreekt of is onvolledig. Voor een afnemer is daardoor niet altijd duidelijk wat een gegeven precies betekent, voor welke situatie het geldt en hoe het moet worden geïnterpreteerd.

Historie wordt vaak slechts beperkt bijgehouden. Soms is alleen de actuele toestand beschikbaar, in andere gevallen is die beperkt tot eendimensionale wijzigingshistorie. En als wel volledige historie in twee dimensies wordt bijhouden, zorgt het toestaan van wijzigingen in de registratietijdlijn (bijvoorbeeld als gevolg van rechtelijke uitspraken) dat het stellen van een gegarandeerd herhaalbare vraag moeilijk niet mogelijk is.

Ook het betwisten en corrigeren van gegevens is vaak onvolledig ondersteund. Wanneer een afnemer een mogelijke fout constateert, bestaat er meestal geen gestandaardiseerde manier om die constatering zichtbaar te maken voor andere afnemers. Terugmeldprocessen bestaan meestal wel op organisatieniveau, maar de koppeling tussen deze processen en de registers die betwiste gegevens leveren zijn niet altijd goed ingericht.

Een combinatie van bovenstaande zorgt ervoor dat het vaak niet mogelijk is mutaties met terugwerkende kracht uit te voeren. Dit betekent dat fouten die het nodig maakt niet-actuele informatie te corrigeren, niet kunnen worden hersteld. Dit betekent dat betrokkenen blijvend met de gevolgen van foute gegevens geconfronteerd worden.

Deze beperkingen waren lang onvermijdelijk en werden, afgezet tegen geboekte efficiëntiewinst, als acceptabel beschouwd. Maar nu overheidsorganisaties de ambitie hebben (zie hieronder) veel vaker elkaars gegevens gebruiken als grondstof voor nieuwe besluiten en gevolgen, en dat bovendien bij de bron te doen, wordt het belangrijk dat verstrekkingen ook context, betwistbaarheid, reproduceerbaarheid en passende toegang ondersteunen.

Overheidsbrede ontwikkelingen

De De Architectuur Digitale Overheid 2030 onderkent de belangrijke rol van data bij (proactieve) beleidsontwikkeling en dienstverlening van de overheid. Om wildgroei en kwaliteitsverlies te voorkomen, willen we die data liever vanuit een aangewezen bron hergebruiken dan (steeds) opnieuw inwinnen.

Bovenstaande lukt alleen als partijen in de FDS-rol van data-aanbieder hun data zodanig kunnen vastleggen en beschikbaar stellen dat die een bruikbare basis vormt voor FDS-datadiensten.

Als het gaat om vernieuwing van het fundament van de overheidsinformatievoorziening wordt ook verder in de toekomst gekeken. De geautomatiseerd uitvoerbare regels van Regelrecht zouden veel gegevensopslag overbodig kunnen maken. En Chronolexografie is een manier om heel gestructureerd rechtstoestanden - oftewel “hetgeen juridisch gezien het geval is (geweest)” - vast te leggen en te reproduceren.

Helpende uitgangspunten

De hierboven beschreven aandachtspunten en ontwikkelingen beschrijven een deel van de context waarbinnen deze handreiking tot stand kwam. Onderstaande uitgangspunten helpen te begrijpen hoe we ons tot die context verhouden en wat deze handreiking wel en niet beoogt.

Gegevens betrekken ‘bij de bron’

We kopiëren te veel gegevens zonder mechanismen om kwaliteit en actualiteit van die kopieën te waarborgen. Deze handreiking is erop gericht de noodzaak voor het maken van gegevenskopieën bij uitvoeren van publieke dienstverleningsprocessen waar dat haalbaar is weg te nemen.

Onderscheid maken tussen proces en resultaat

We erkennen een verschil tussen formeel beschreven of informeel uitgevoerde processen en daaruit voortkomende resultaten. Een proces vertelt hoe de overheid handelt. Als resultaat daarvan ontstaat iets met betekenis of waarde. Deze handreiking gaat niet over procesautomatisering, maar beschrijft op welke manier we de resultaten daarvan zo goed mogelijk kunnen vastleggen en beschikbaar stellen.

Onderscheid maken tussen gevolg (betekenis) en verstrekking (representatie)

Als het gaat om bovengenoemde resultaten, erkennen we het verschil tussen betekenis van een resultaat - dat we gevolg noemen, en communicatie daarover, waarvoor een representatie (verstrekking) nodig is. Het verenigen van deze concepten in één artefact - bijvoorbeeld een akte - draagt bij aan ontstaan van ‘vormfouten’ (bijvoorbeeld het onjuist overnemen van een juiste conclusie in een besluit of databasetabel) in de hand.

Hoewel sprake is van een afhankelijkheidsrelatie - de verstrekking is (via een projectie) afgeleid van het gevolg - zijn ze vanuit verantwoordingsperspectief van even groot belang. Het gevolg betekenis als ‘kern’ van wat bedoeld werd, en de verstrekking als hetgeen op basis waarvan anderen (mogelijk) hebben gehandeld.

Bij deze conceptualisatie past de metafoor van de januskop of het hoofd met twee gezichten. Janus deelt één brein - dus een gedeelde, onderling verbonden hoeveelheid kennis, met daarop twee perspectieven, ingegeven door twee paar zintuigen. Het ene paar blikt terug op een proces dat een bepaald resultaat - of gevolg opleverde, terwijl het andere paar vooruit kijkt, richting door verstrekkingen van die gevolgen in gang gezette vervolghandelingen.

Janus(kop)

Afbeeldingscredit Igor Gordeev

In de beeldhouwkunst en schilderkunst is een januskop een hoofd met zowel aan de voorzijde als aan de achterzijde een gezicht. Het is genoemd naar de Romeinse god Janus, die in een van zijn verschijningsvormen twee gezichten had.

Janus was een Romeinse god die heerste over alle begin en overgang. Vóór hij door Jupiter tot god met twee gezichten gemaakt werd, heerste hij volgens legende als koning over Latium. Daar werd hij beschouwd als stichter van het maatschappelijke leven en van de maatschappij, die de mensen verloste uit hun barbaarse toestand en tot een ordelijk leven bracht.

Onderscheid maken tussen bijhouding en verstrekking

Gelijktijdig erkennen van het verschil tussen, en gelijkwaardig belang van gevolg en verstrekking, vraagt in registerarchitectuur om onderscheid tussen bijhouding en verstrekking. Dit maakt het mogelijk om op de specifieke informatiebehoefte van bepaalde afnemers (of verstrekkingsconsumenten_) toegesneden projecties te leveren.

De wens onnodige kopieën te vermijden vraagt erom deze perspectieven op één onderliggende werkelijkheid beide als bron met zelfstandig bestaansrecht te beschouwen. Aandachtsgebieden voor betrouwbare registers zijn dan ook voor beide perspectieven relevant. De begrippen gevolgenjournaal en projecties gebruiken we om de gegevensverzamelingen die bij de perspectieven horen te onderscheiden.

Conceptueel model van een betrouwbaar register

Beschrijving van het conceptueel model

In het kort

De hoofdlijn van het model is te lezen van links naar rechts. Een uit een externe bevinding vertaald of rechtstreeks aangeboden commando komt ‘onze’ bounded context binnen. Optekenen produceert op basis van het commando één of meerdere gevolgen, opgebouwd uit gevolgdelen, met herkomst en tijd, en voegt dat toe aan het journaal. Projecteren leidt uit dat journaal projecties af - elk met een eigen bereik en vorm - waarin zekerheid en onderschrijving zichtbaar zijn. Deze projecties zijn de bron voor verstrekkingen aan afnemers met referenties die verificatie en herlevering mogelijk maken. Langs deze verstrekkingskant kunnen ook terugmeldingen worden aangeboden, die als betwijfeling het journaal ingaan en als zekerheidsindicatie verstrekt worden.

Bewering als bouwsteen

Een register bevat beweringen. Zo’n bewering is een eenheid van gegevens die op basis van herkomst en tijd als geheel wordt beschouwd en waarvan de juistheid als geheel staat of valt. Een bewering valt dus niet uiteen in delen waarvan de juistheid afzonderlijk zou kunnen worden beoordeeld. Wat samen wordt vastgelegd, wordt samen betwist en samen ingetrokken.

Een gegeven is het kleinste betekenisdragende onderdeel van een bewering. Losse gegevens komen in het register niet voor; een gegeven bestaat alleen binnen een bewering en ontleent daaraan zijn herkomst en zijn plaats in de tijd.

Een bewering kan twee beschrijvingsvormen aannemen. Iets kan worden beschreven als iets dat op ieder bestaansmoment een toestand heeft; dat is een continuant. Iets kan ook worden beschreven als een gebeuren dat zich in de tijd voltrekt; dat is een occurrent.

Bounded contextmodel

Een register beweert binnen een afgebakend domein in een gemeenschappelijke taal over een beperkt aantal soorten dingen. Dat geheel heet het bounded contextmodel: het model dat beschrijft wat er gebeurt als een bewering wordt opgenomen. Het beschrijft welke toestand verandert, vanaf wanneer en wat daarmee ophoudt te gelden.

De beweringssoort geeft aan welke soorten beweringen het register kan produceren en welke gegevenssoort daarbinnen kan voorkomen. De waardelijst begrenst het waardenbereik van een gegevenssoort. De beweringssoort is ook de basis voor betekenis, die bepaalt wat beweringen van dezelfde soort uitdrukken.

Het entiteittype geeft aan over welke soorten dingen het register kan beweren en welke gegevenssoort een ding van dat type identificeert.

De inwerkingsregel verbindt beweringssoort en entiteittype, en beschrijft of een bewering een entiteit doet ontstaan dan wel het bestaan daarvan veronderstelt, en hoe zo’n bewering doorwerkt in wat over die entiteit beweerd wordt.

Entiteit

Het register beschrijft dingen: personen, gebouwen, huwelijken, voertuigen. In het model heten die entiteit. Dat het begrip in het cluster kernconcepten staat en niet in een van de concrete clusters, is geen toeval. Het register houdt geen entiteiten bij; het houdt beweringen bij over entiteiten.

Wat die beweringen met elkaar verbindt, is de identiteit. Het register geeft, als onderdeel van een identiteitsverlenend gevolgdeel, een identificerend kenmerk uit waarmee beweringen die één entiteit beschrijven aan die entiteit kunnen worden gerelateerd. Wat het register over een entiteit beschikbaar heeft is het geheel van beweringen die naar dezelfde identiteit verwijzen.

Commandoverwerking

Registers werken zelden in isolatie. Ze ontvangen informatie van andere registers, van andere overheidsorganisaties en van burgers, en die informatie gebruikt de begrippen van een andere context. Bijhouding vindt plaats in de taal van de eigen bounded context en overname vraagt dus om vertaling.

Wat van buiten binnenkomt, is een externe bevinding: een uitspraak die buiten de bounded context van het register is ontstaan. Een vertaalregel beschrijft hoe die met behoud van betekenis wordt omgezet naar een contexteigen commando, een opdracht aan het register om een gevolg op te tekenen. De functie die de omzetting uitvoert heet Overzetten.

De vertaalregel maakt ook duidelijk wat achterblijft. Een geboorteakte bevat een tijdstip van geboorte; een register dat alleen geboortedata kent, neemt dat tijdstip niet over. Deze regel maakt de capability Expliciteren van contextovergangen, ofwel het vermogen inzichtelijk te maken hoe bevindingen van buiten de registercontext daarbinnen bruikbaar worden gemaakt, mogelijk.

Gevolgenjournaal

Een gevolg is een bewering waarmee een daartoe bevoegde actor performatief handelt, die binnen een bepaalde context een basis vormt voor vervolghandelingen en waarop betrokkenen die actor kunnen aanspreken. Het gevolg beschrijft altijd iets dat zich heeft voltrokken.

Performatief betekent dat de uitspraak niet iets beschrijft maar iets tot stand brengt. Dat de gemeente vastlegt dat iemand op een adres woont, maakt dat hij daar voor de overheid woont, met de rechten en verplichtingen die daaraan verbonden zijn. Een gevolg hoeft daarvoor geen bijzondere grammaticale vorm te hebben. “Persoon p1 is verhuisd naar adres a1” is een mededelende zin en toch performatief, omdat het optekenen ervan door de bevoegde actor het institutionele feit vestigt. Bepalend zijn de bevoegdheid en de context, niet de vorm van de zin.

Een gevolg is een primair feit, dat niet opnieuw uit zijn invoer af te leiden is. Wie hetzelfde commando opnieuw zou aanbieden, handelt opnieuw performatief en krijgt dus niet hetzelfde, maar een nieuw gevolg.

Gevolgen worden vastgelegd in het gevolgenjournaal: een onveranderlijke en geordende vastlegging van alle gevolgen die binnen een bepaalde context zijn geproduceerd.

Voor meer details, zie de verdieping.

Hoe een gevolg tot stand komt

De functie Optekenen produceert op basis van commando’s gevolgen uit gevolgdelen en voegt die toe aan het register. Optekenen leest daarvoor drie dingen: het commando, de vormingsspecificatie die beschrijft welke gevolgen op basis van het commando moeten worden geproduceerd en uit welke gevolgdelen die worden opgebouwd, en de opnametoestand.

De opnametoestand is een uit het gevolgenjournaal afgeleide toestand waartegen wordt vastgesteld of een commando tot gevolgen kan leiden, en waaruit voor de inhoud van die gevolgen gegevens worden overgenomen. De opnametoestand vervult dus twee functies: toetsing, bijvoorbeeld op de vraag of de persoon over wie het commando gaat bestaat en of de akte niet al eerder is verwerkt, en levering van gegevens. Wanneer een persoon ingeschreven wordt in het bevolkingsregister, komen de persoonsgegevens uit de opnametoestand en niet uit het commando (zie het inschrijving op geboortedatum voorbeeld).

Een gevolg wordt opgebouwd uit gevolgdelen. Een gevolgdeel is een bouwsteen die wordt gebruikt binnen het productieproces van gevolgen en daarbuiten niet bestaat. Gevolgdelen verlaten het cluster niet en zijn na productie niet zelfstandig aanwijsbaar; wat in het journaal staat en waarnaar later kan worden verwezen, is het gevolg. Het model kent drie soorten, elk met een eigen functie.

Een identiteitsverlenend gevolgdeel verleent een entiteit binnen het register identiteit en maakt die daarmee aanwijsbaar. De bijbehorende functie is Identiteit verlenen.

Een primair gevolgdeel omvat een bewering uit het domein over een entiteit. De bijbehorende functie is Opstellen.

Een beweringsgericht gevolgdeel gaat over een bewering. Het verandert niets aan wat het register over het domein zegt, maar aan de houding die het register inneemt tegenover een eerdere vastlegging. Er zijn drie soorten: een betwijfeling trekt de juistheid van een bewering in twijfel, een betwijfelingsopheffing neemt die twijfel weer weg, en een onttrekking trekt de onderschrijving van een bewering in. De bijbehorende functies zijn Betwijfelen, Betwijfeling opheffen en Onttrekken.

Correcties

Correctie is geen apart mechanisme in dit model. Een correctie ontstaat doordat de bestaande functies binnen één optekening worden aangeroepen in de samenhang die het geval vraagt, bijvoorbeeld een onttrekking van de onjuiste bewering en een primair gevolgdeel met de juiste inhoud, samen in één gevolg.

Voor meer details, zie de verdieping. Zie de correctie van een verhuizing voor een eerste voorbeeld.

Herkomst en tijd

Elke bewering kent herkomst en tijd.

Herkomst beschrijft welke bron aan een bewering ten grondslag heeft gelegen, wie voor de productie verantwoordelijk is, welke legitimering daarbij is toegepast en welke werkwijze is gevolgd. De bron is de grond waarop de bewering rust: een eerdere bewering, een eigen waarneming of een getuigenis. Het model legt daarbij één stap terug vast en niet de hele keten. Wanneer een register een eigendomsovergang opneemt op grond van een notariële akte, is die akte de bron; de overeenkomst die aan de akte voorafging, hoort bij de herkomst van de akte. Wie de hele keten wil volgen, doet dat stap voor stap, omdat elke schakel een eigen herkomst heeft.

De verantwoordelijke identificeert wie voor de productie instaat, ook wanneer de uitvoering geautomatiseerd is verlopen; automatisering verplaatst de verantwoordelijkheid niet naar het systeem. De legitimering geeft het kader aan op grond waarvan is geproduceerd en hoe dat kader is toegepast, inclusief eventuele discretionaire afwijkingen. De werkwijze legt vast volgens welke procedure of welk algoritme, en in welke versie, een bewering tot stand kwam. Waar de bron in een document is vastgelegd, verwijst het model daarnaar.

Tijd valt uiteen in twee soorten. De domeintijd is het punt of de periode die onlosmakelijk hoort bij wat een bewering beschrijft. De systeemtijd is het punt dat het register bij het vastleggen toevoegt. De geboortedatum van een op 3 maart geboren kind is een moment in een domeintijdsdimensie. Het moment (bijvoorbeeld 5 maart) waarop het inschrijvingsgevolg met die geboortedatum door het register wordt opgenomen is een moment op de systeemtijdlijn. In de voorbeelden is een adoptievoorbeeld te vinden waarop verschillende domeintijdstippen per projectie een rol spelen.

Waar aan de domeintijdkant meerdere tijdsdimensies kunnen bestaan — bijvoorbeeld een geldigheidsperiode naast een moment van inwerkingtreding — is er één systeemtijddimensie. Die dimensie manifesteert zich op twee plekken: aan de journaalkant als gevolgtijdstip (het moment waarop een gevolg in het gevolgenjournaal wordt vastgelegd) en aan de projectiekant als projectietijdstip (het moment waarop een projectie-element beschikbaar komt voor afnemers). Tussen deze twee momenten zit verwerkingstijd. Het zijn twee verschijningsvormen van dezelfde as, niet twee onafhankelijke dimensies.

Voor meer details over de verschillende soorten tijdstippen, zie de verdieping over tijdstippen en geldigheid.

Rol van projecties

Het gevolgenjournaal is heel geschikt voor verantwoording, maar in veel gevallen geen praktische bron voor bevragingen. Wie wil weten waar iemand nu woont, wil voor een antwoord niet alle adreswijzigingen sinds 1994 moeten afspelen. Dus maken we voor het beantwoorden van dit soort vragen projecties. Een projectie is een uit het gevolgenjournaal afgeleide, op de informatiebehoefte van afnemers toegesneden verzameling van projectie-elementen.

Die afstemming op de informatiebehoefte van afnemers vereist dat één journaal meerdere projecties kan voeden, elk met een eigen bereik en een eigen vorm. De bijbehorende capability is Onderhouden van projecties op maat: het vermogen meerdere projecties te onderhouden die aansluiten bij de informatiebehoefte van specifieke doelgroepen.

Soorten projecties

Een projectie heeft één van twee hoofdvormen. Een toestandsprojectie beschrijft entiteiten als iets dat een toestand heeft, een gebeurenprojectie als gebeuren dat zich in de tijd voltrekt. Dit onderscheid bepaalt de vragen die een afnemer aan een projectie kan stellen. Op basis van een toestand kan worden gevraagd wat er op enig moment gold; van een gebeuren kan worden gevraagd wanneer het plaatsvond en wat eraan voorafging. Met deze hoofdvormen als basis van kunnen vijf archetypische projecties worden onderscheiden.

Aan de toestandskant zijn dat er drie:

1. De actueel geldige toestand bevat de elementen die het register nu onderschrijft en die in de domeintijd actueel gelden.
2. In domein geldige historische toestanden bevat de elementen die het register nu onderschrijft en die in de domeintijd ooit geldig waren.
3. Alle historische toestanden bevat de elementen die het register ooit heeft onderschreven, dus ook wat later is ingetrokken. Die laatste is nodig voor verantwoording: een afnemer die handelde op basis van een gegeven dat later onjuist bleek, moet kunnen aantonen dat het register dat gegeven ooit juist achtte.

Aan de gebeurenkant zijn er twee projectie-archetypen:

1. Het onderschreven verloop bevat de gebeurenelementen die het register nu onderschrijft.
2. Het volledig verloop omvat aanvullend de elementen het ooit wel onderschreef, maar inmiddels niet meer onderschrijft.

Projecties opbouwen

Een projectiespecificatie beschrijft per projectie hoe gevolgen daarin doorwerken en operationaliseert daarmee de inwerkingsregels uit het contextmodel. De functie Projecteren leest een gevolg en werkt op basis de inhoud daarvan en de projectiespecificatie de projectie bij. Projecteren bestaat uit vier deelfuncties: Openen opent een reeks voor een entiteit die nog niet voorkwam, Bijwerken legt een nieuwe toestand vast in een toestandsprojectie-element, terwijl Bijschrijven een gebeurenprojectie-element aan de projectie toevoegt. Bijstellen legt een veranderd oordeel over de inhoud van een projectie-element vast.

Een reeks is het geheel van projectie-elementen binnen één projectie over dezelfde entiteit. De reeks groepeert wat over hetzelfde ding is vastgelegd en is daarmee de plek waar de identiteit uit het gevolgencluster doorwerkt.

Door het bijwerken van projecties te laten verlopen via deze vier standaardoperaties — ongeacht het soort gevolg dat wordt verwerkt — verkleint het register de kans op verwerkingsfouten. Elke verwerking volgt hetzelfde patroon; alleen de projectiespecificatie bepaalt hoe een concreet gevolg doorwerkt. Deze standaardisatie is een aanbevolen ontwerppatroon voor robuuste projectieopbouw.

Voor meer details, zie de verdieping voor temporaliteit in projecties en het bijwerken van projecties.

Zekerheid en onderschrijving

Projectie-elementen hebben twee metagegevens die gevolgen niet hebben.

Zekerheid geeft aan of het register de juistheid van een projectie-element betwijfelt. De betwijfelingen en betwijfelingsopheffingen in het gevolgenjournaal vormen daarvoor de basis. Een betwijfeld element wordt nog steeds geleverd, met de vermelding dat het register aan de juistheid twijfelt. Dat helpt een afnemer te bepalen of het element nog geschikt is als basis voor gevolghandelingen. zie de twijfelvoorbeelden in de WOZ casus.

Onderschrijving geeft aan of het register een projectie-element onderschrijft. Een in het gevolgenjournaal opgetekende onttrekking vormt daarvoor de grond. Een niet-onderschreven element verdwijnt uit de projecties die alleen onderschreven elementen tonen. Zie onttrekkingen in de WOZ casus.

Verstrekken

Een verstrekking is een geheel van projectie-elementen dat het register in een bepaalde vorm uitgeeft. Het model onderscheidt twee soorten. Een notificatiebericht geeft het register op eigen initiatief uit, terwijl een antwoordbericht op aanvraag van een afnemer wordt geleverd. De bijbehorende functies zijn Melden en Bevraging beantwoorden.

De capability Betekenisvol notificeren houdt in dat het register notificaties kan leveren die informatie omvatten over de aanleiding voor en de betekenis van de beweringen waarover wordt genotificeerd. Het gebeurtenisachtige karakter dat daarvoor nodig is, betekent dat melden altijd gebeurt op basis van een gebeurenprojectie. Zie voor een privacybeschermend voorbeeld de adoptiecasus in de BRP voorbeelden.

Elke verstrekking bevat een verstrekkersreferentie: een metagegeven dat verwijst naar die specifieke verstrekking, te gebruiken om de inhoud te laten verifiëren of om die opnieuw te ontvangen. Daarop rusten twee capabilities.

Herleveren op aanvraag is het vermogen een eerder uitgegeven verstrekking met dezelfde inhoud in identieke vorm opnieuw te verstrekken. Attesteren is het vermogen een verklaring uit te geven die aantoont dat een verstrekking met een bepaalde inhoud door het register is gedaan. De functie Verifiëren produceert dat leveringsattest.

Ook de capability Historisch inzicht hoort in dit cluster thuis: het vermogen historische beweringen te leveren, zowel naar domeintijd als naar systeemtijd. Beide zijn nodig, de eerste om te leveren wat ooit gold, de tweede om te leveren wat het register ooit onderschreef. Zie de correcties voor BRP als WOZ, bijvoorbeeld het corrigeren van eigenaarschap in de WOZ, voor bitemporele bijhoudingen.

Betwisten

Een terugmelding is een melding waarmee de juistheid van een geleverd projectie-element wordt betwist. De functie Betwisten vecht die juistheid aan. De capability Terugmelden is het vermogen te laten melden dat een geleverd projectie-element vermoedelijk onjuist is.

De terugmelding is de ingang waarlangs twijfel het register binnenkomt. Die twijfel loopt via een betwijfeling het gevolgencluster in en komt als zekerheid aan de leverkant weer naar buiten. Zie de terugmeldingvoorbeelden.

Vernietigen

De functie Blijvend ontoegankelijk maken maakt een bewering blijvend ontoegankelijk, zodat de inhoud niet gereconstrueerd kan worden. Wat overblijft is een merkteken: een markering die getuigt van het bestaan van een bewering, zonder iets te vertellen over de inhoud daarvan.

Het merkteken houdt het register ook na vernietiging begrijpelijk. Een journaal waaruit stilzwijgend iets kan verdwijnen, is niet te verantwoorden; door een markering achter te laten blijft zichtbaar dat er iets was, zonder prijs te geven wat.

Aan deze functie zijn twee capabilities verbonden. Deze vereisen een vergelijkbare handeling, met verschillende grondslagen. Vernietigen is het vermogen vernietigingshandelingen uit te voeren conform Archiefwettelijke eisen; daar verstrijkt een bewaartermijn en volgt vernietiging uit het register zelf. Vergeten is het vermogen gegevens te wissen conform het recht op vergetelheid uit de Algemene Verordening Gegevensbescherming; daar komt de aanleiding van buiten, van een betrokkene, en gaat er een afweging aan vooraf.

Verdieping: registerbreed

Als we registers werkelijk capabel en betrouwbaar willen maken, moeten we vanaf het eerste ontwerp met een aantal belangrijke aspecten rekening houden.

Deze aspecten worden hieronder in algemene zin beschreven. In de hoofdstukken hierna beschrijven we hoe ze specifiek doorwerken in het gevolgenjournaal en projecties.

Terugmelden

Terugmelden is het proces waarbij een afnemer van gegevens aan de bronhouder meldt dat hij twijfelt aan de juistheid van verstrekte gegevens.

De term is afkomstig uit het stelsel van basisregistraties. Binnen dat stelsel zijn overheidsorganisaties verplicht twijfel over de juistheid van gegevens aan de bronhouder te melden.

Functioneel is het principe echter breder toepasbaar: overal waar gegevens worden gedeeld tussen een beheerder en afnemers, kan terugmelden als mechanisme dienen om de kwaliteit van die gegevens gezamenlijk te bewaken.

Onderzoeken

Na een terugmelding moet de bronhouder beoordelen of de gemelde twijfel gegrond is. Daartoe onderzoekt hij of de betreffende projectie inderdaad onjuist is, en zo ja, of die onjuistheid te herleiden is naar één of meer onjuist geregistreerde gevolgen - en mogelijk andere daarvan weer afgeleide projecties.

Dit onderzoek vindt plaats buiten het register, bijvoorbeeld in een zaaksysteem of ander procesondersteunend systeem. Gedurende het onderzoek kunnen in het register wel indicaties van twijfel worden aangebracht, zodat afnemers weten dat over de juistheid van bepaalde projecties of gevolgen onzekerheid bestaat.

Corrigeren

Wanneer het onderzoek onjuistheden aan het licht brengt, corrigeert de bronhouder de betrokken gegevens.

Verwerkingsverantwoording

Een betrouwbaar register legt niet alleen vast wat er is gebeurd, maar ook waarom en hoe dat is gebeurd. Deze contextinformatie hoort bij het aspect dat we verwerkingsverantwoording noemen. Verwerkingsverantwoording stelt afnemers in staat de betekenis en herkomst van een gegeven te beoordelen, en maakt het mogelijk fouten te herleiden en te herstellen. Verwerkingsverantwoording valt in drie onderdelen uiteen:

1. aanleiding
2. legitimering
3. verklaring

Aanleiding

De aanleiding beschrijft wat de productie van een gevolg in gang heeft gezet. In veel gevallen is dat een eerder in de keten geproduceerd gevolg. Als zo’n voorliggend gevolg ontbreekt, is de aanleiding gelegen buiten de overheidscontext, bijvoorbeeld in een handeling of melding van een burger of bedrijf.

Legitimering

Met legitimering bedoelen we het wettelijk of beleidskader dat diende als grondslag voor de productie van een gegeven.

Verklaring

Met de verklaring wordt duidelijk gemaakt op welke manier het legitimerende kader in een specifieke situatie is gehanteerd. Denk daarbij aan informatie over toegepaste procedures, versieaanduidingen van gebruikte algoritmes of de motivatie van een ambtenaar die op basis van discretionaire bevoegdheid van een norm afweek.

Geldigheid

Geldigheid beschrijft wanneer en op wiens gezag iets ‘gold’ of beschouwd werd als ‘juist’ of ‘waar’. Geldigheidstijd is daarmee een vorm van domeintijd: de overkoepelende categorie voor tijdsaspecten die worden bepaald door wat het register beschrijft, niet door het register zelf.

Geldigheid wordt bepaald door het administratieve domein dat gegevens registreert. In tegenstelling tot de registratiecontext — en de systeemtijd die daarvan het temporele aspect vormt — is geldigheid een onveranderlijk of ‘intrinsiek’ onderdeel van hetgeen geregistreerde gegevens beschrijven. Gegevens die in meerdere registers gedupliceerd zijn, hebben als logisch gevolg hiervan in ieder van die registers dezelfde geldigheid.

Geldigheid als administratief construct

Hoewel het woord ‘intrinsiek’ anders kan doen lijken, is geldigheidstijd een administratief construct. Niemand zal kersverse ouders immers een kaartje sturen om te ze te feliciteren met de nieuwverworven geldigheid van hun pasgeboren baby. In de ‘echte’ wereld, waar de dingen die we met behulp van gegevens beschrijven daadwerkelijk bestaan, komen we dus hooguit gebeurtenissen tegen die aanleiding geven om gegevens in administratieve context als geldig te gaan beschouwen. In het geval van een persoon kan dat een geboorte zijn, maar bijvoorbeeld ook een immigratie als iemand pas op latere leeftijd in beeld komt van ‘onze’ administratieve werkelijkheid. Overlijden zou aan de andere kant een reden kunnen zijn om de geldigheid van een persoon te beëindigen.

Registratiecontext

Registratiecontext beschrijft wanneer en door wie — welke medewerker of afdeling — iets is vastgelegd. Het temporele aspect (“wanneer”) is wat systeemtijd heet; het “door wie”-aspect valt onder herkomst en verantwoordelijke. Registratiecontext is daarmee breder dan systeemtijd alleen. Voor het temporele aspect gebruikt de rest van de handreiking consequent de term “systeemtijd”.

In tegenstelling tot geldigheid is de registratiecontext niet onverbrekelijk gebonden aan een set gegevens. De registratiecontext wordt ten opzichte van daarvan daarom ook wel als ‘extrinsiek’ beschouwd.

De registratiecontext wordt bepaald en vastgelegd door het systeem waarin gegevens worden bijgehouden. Dit kan een IT-systeem zijn, maar ook het sociotechnische systeem waarin mensen en IT-systemen samenwerken om taken uit te voeren. Dit betekent dat gegevens die in meerdere systemen zijn vastgelegd, in ieder van die systemen verschillende registratiecontexten hebben.

Bespiegeling over tijd

De aandachtsgebieden geldigheid en registratiecontext zijn sterk verbonden met het concept tijd. Over dit onderwerp in relatie tot registers zijn boekenkasten vol geschreven. Daarin worden eindeloos veel verschillende ‘tijdsoorten’ of ‘tijdsassen’ genoemd. Binnen deze handreiking maken we primair onderscheid op basis van wie of wat de waarde van een tijdstip of periode bepaalt.

Bij domeintijd wordt de temporele waarde bepaald op basis van de werkelijkheid, de regelgeving of de bestuurlijke context waarbinnen een registratie werkt. Geldigheidstijd is het bekendste voorbeeld, maar ook de voltrekkingstijd — het tijdstip waarop een gebeuren zich voltrekt — valt hieronder, evenals juridische inwerkingtredingsdata of beslistermijnen. Domeintijd is intrinsiek, dus onlosmakelijk onderdeel van en verbonden met het gebeuren of de toestand die een registratie beschrijft.

Bij systeemtijd wordt de waarde bepaald door het IT- of sociotechnische systeem dat gegevens verwerkt en opslaat. Systeemtijd is per definitie extrinsiek: het zegt iets over de verwerking van een registratie binnen een systeem, maar niets inhoudelijks over het gebeuren of de toestand die een registratie beschrijft.

Zekerheid

Met zekerheid bedoelen we de mate waarin een registratie als feitelijk juist wordt beschouwd. Zekerheid is om twee redenen geen eenvoudig begrip. Ten eerste is het gradueel: een registratie kan geverifieerd en onbetwist zijn, maar ook onbevestigd, in onderzoek, of actief betwist. Ten tweede is zekerheid niet altijd gedeeld: verschillende partijen kunnen op hetzelfde moment een verschillend oordeel hebben over de juistheid van dezelfde registratie.

(On)zekerheid werkt diep door in ketens of netwerken. Als een bedrijfsregel bij het afleiden van een resultaat steunt op een gegeven waaraan getwijfeld is, is immers ook dat resultaat onzeker. Als datzelfde resultaat door andere partijen in de keten gebruikt weer wordt gebruikt als basis voor eigen handelingen, kunnen weer nieuwe op onjuiste gronden gefundeerde resultaten ontstaan, enzovoorts.

Onttrekking

Onttrekking is het logisch ongedaan maken van een registratie in een overheidsregister, zonder dat de bijbehorende gegevens fysiek worden verwijderd.

In een betrouwbaar register verwijderen we geen gegevens die we mogelijk ooit hebben geleverd. Fysiek verwijderen levert op conceptueel niveau geschiedvervalsing op en breekt op functioneel niveau de garantie op de herhaalbare vraag. Om historische vastleggingen gegarandeerd te behouden, hanteren we voor het gevolgenjournaal en projecties een append only-patroon: gegevens worden alleen toegevoegd, nooit overschreven of verwijderd.

Aanleidingen voor onttrekking

Om de reden voor het onttrekken van gegevens goed te begrijpen, is het eerst nodig om onderscheid aan te brengen tussen twee verschillende vormen van juistheid:

1. Feitelijke juistheid verwijst naar de mate waarin geregistreerde gegevens een accurate weergave vormen van de fysieke, juridische of administratieve werkelijkheid die ze representeren.
2. Systeemjuistheid verwijst naar de mate waarin het register gegevens verwerkt op de manier waarop wie die verwerking heeft gespecificeerd of bedoeld had, ongeacht of die gegevens zelf feitelijk juist waren.

Vervolgens kunnen we (tenminste) de volgende aanleidingen onderscheiden:

• Feitelijk onjuiste gegevens aangeboden. Door verkeerde informatie, een vergissing of een technisch mankement zijn gegevens aan het register aangeboden die feitelijk onjuist zijn, op basis waarvan feitelijk onjuiste gevolgen en mogelijk feitelijk onjuiste projecties zijn geproduceerd.
• Onjuiste verwerking geconstateerd. Door een gebrek aan systeemjuistheid zijn feitelijk juiste gegevens niet op de bedoelde manier verwerkt, waardoor feitelijk onjuiste gevolgen en/of projecties zijn geproduceerd.
• Verzoek tot vergeten. Een burger heeft op basis van de Algemene verordening gegevensbescherming verzocht een feitelijk juiste registratie te laten verwijderen.
• Bewaartermijn verlopen. De archiefwettelijke bewaartermijn voor een registratie is verstreken.
• Nieuw begrip van feitelijke juistheid. Naar aanleiding van juridische of beleidsmatige heroverweging kunnen gegevens die eerder als feitelijk juist werden beschouwd niet langer als zodanig worden aangemerkt.
• Ethische of maatschappelijke overweging. Het behouden van een feitelijk juiste registratie wordt op basis van ethische of maatschappelijke overwegingen als ongewenst beschouwd.

Gevolgen van onttrekking

Onttrokken gevolgen zijn niet langer beschikbaar voor ‘normaal’ gebruik. Onttrokken gevolgen worden niet meer getoond in standaardprocessen, rapportages of openbare inzage en zijn niet langer beschikbaar voor normaal gebruik door ambtenaren, burgers of geautomatiseerde systemen.

Bespiegeling: is onttrekking een gevolg?

De vraag is of onttrekking zelf als gevolg moet worden beschouwd. Het alternatief is onttrekking te behandelen als een abstract supertype - een op technisch niveau geïmplementeerd begrip dat in de administratieve praktijk verschijnt in herkenbaarder vormen zoals correctie, herstel, herroeping of vergeten in de context van het AVG-recht op vergetelheid.

Verdieping: gevolgenjournaal

Betekenis en doel

Het gevolgenjournaal is een volledige en onveranderlijke vastlegging van alle gevolgen die binnen een register werden geproduceerd, in de volgorde waarin die gevolgen ontstonden. De naam is ontleend aan het scheepsjournaal, waarin door nauwkeurige waarnemers volledig, chronologisch, zonder weglating én zonder oordeel wordt genoteerd wat is waargenomen.

Het gevolgenjournaal richt zich uitsluitend op het nauwkeurig vastleggen van wat er is gebeurd: observaties, besluiten en registraties. Afnemers en hun informatiebehoeften spelen daarin geen rol. Het principe is: negeer de afnemer. Dit uitgangspunt geldt zo sterk mogelijk, maar de gevolgen vormen wel de grondstof op basis waarvan de informatiebehoefte van afnemers - voor zover realistisch en redelijk - moet worden ingevuld.

Gevolgen leggen zonder oordeel vast wat er is waargenomen of besloten. Ze drukken daarmee de intentie van een observatie of besluit uit – niet het effect ervan op de toestand van het register. Gevolgen zijn temporeel atomair: ze gebeuren op één moment, en hebben (dus) geen duur. Geboortes, verhuizingen of huwelijken markeren geen toestand, maar beschrijven de verandering die van de ene toestand leidt naar de volgende. Gevolgen zijn daarmee een voorbeeld van wat transitional modeling of overgangsmodellering wordt genoemd.

Vraagstuk: gevolgen feitelijk of administratief formuleren?

Gevolgen kunnen we op twee manieren formuleren:

1. Feitelijk, beschouwd vanuit de werkelijkheid waarop dat handelen betrekking heeft - ongeacht de wijze waarop het administratief is verwerkt of vastgelegd. Bijvoorbeeld "persoon p1 geboren".
2. Administratief, beschouwd vanuit de administratieve context waarbinnen dat handelen heeft plaatsgevonden - dat wil zeggen: de registratie, vastlegging of formalisering van een feitelijk gevolg binnen een specifiek overheidsproces. Bijvoorbeeld: "geboorte persoon p1 geregistreerd".

Welke van de twee we kiezen heeft effect op de aandachtsgebieden geldigheid en zekerheid. Zie de toelichting onder de corresponderende koppen.

Aandachtsgebieden in het gevolgenjournaal

Terugmelden

Terugmelden gebeurt door afnemers op een projectie die onderdeel is van projecties, en dus níet (direct) op een gevolg in het gevolgenjournaal.

Onderzoeken

Onderzoek(en) naar aanleiding van een terugmelding gebeuren buiten het register. Zo’n onderzoek zelf leidt dus niet tot nieuwe gevolgen in het gevolgenjournaal. Wel kan uit onderzoek blijken dat bij vermoedelijk onjuiste gevolgen binnen het register indicaties van verminderde zekerheid over de juistheid moeten worden aangebracht.

Deze indicaties kunnen in eerste instantie aangebracht worden op gegevens in één of meerdere projecties (waar een terugmelding op gedaan is), maar kunnen (bijvoorbeeld lopende het onderzoek) verplaatst worden naar indicaties op gevolgen (die dientengevolge alle projecties raken waar het geïndiceerde gegeven gebruikt wordt). Een dergelijke indicatie kan ook als basis dienen van correctie.

Corrigeren

Het gevolgenjournaal is append only: gevolgen worden alleen toegevoegd, nooit overschreven of verwijderd. Correctie betekent dus altijd het toevoegen van een nieuw gevolg dat één of meerdere eerdere gevolgen ongedaan maakt of herziet.

Bij of na correctie zijn er twee fundamentele vragen aan de orde:

1. Hoe had het moeten zijn; of: Hoe had mijn gevolgenjournaal moeten zijn?
2. Wat is er (precies) gecorrigeerd en waarom?

Om beide vragen te kunnen beantwoorden dient een correctiegevolg idealiter dan ook drie dingen te bevatten:

1. Welke gevolgen worden gecorrigeerd?
2. Hoe had de gevolgentijdlijn eruit moeten zien voor deze periode.
3. De exacte hersteloperatie en context

Bij voorkeur gebeurt dat in de taal van de bounded context; een gevolg als "emigratie p1 herroepen" maakt de bedoeling direct duidelijk. Deze aanpak heeft echter een praktische beperking: het is niet goed mogelijk om vooraf alle situaties te voorzien waarin correctie nodig kan zijn. Bovendien vereist ieder domeinspecifiek correctiegevolg dat de bijbehorende bedrijfsregels worden bepaald en geconfigureerd, wat bij een laag correctievolume onevenredig veel ontwerplast met zich meebrengt.

Daarom kan het soms nodig zijn generieke correctiegevolgen te introduceren die domeingevolgen ‘passeren’ en direct inwerken op de begrippen uit projecties, zoals bijvoorbeeld "verblijfsadres p1 gecorrigeerd". Belangrijk is dat zulke correcties altijd in het gevolgenjournaal worden opgenomen en transactioneel worden afgehandeld, zodat het journaal consistent blijft.

In het uitzonderlijke geval dat niet meer te reconstrueren is hoe een bepaalde toestand is ontstaan, maar wel bekend is hoe die eruit zou moeten zien, kan het nodig zijn op basis daarvan een nieuwe historie op te bouwen. Dit soort ingrijpende correcties moet zoveel mogelijk beperkt blijven omdat daarop nauwelijks (al dan niet geautomatiseerde) integriteitscontrole mogelijk is en op basis daarvan moeilijk verstrekt kan worden.

Voor een meer implementatiegerichte beschrijving van correcties is er meer te lezen in een verdieping.

Herkomst

Op basis van het onderscheid tussen proces en resultaat willen we het register niet de wereld van procesuitvoering in trekken. Maar we willen afnemers wel in staat stellen door het register verstrekte gegevens op onder andere betekenis, kwaliteit en juistheid te beoordelen. Herkomst is daardoor binnen het gevolgenjournaal een belangrijk aandachtsgebied. Dit bestaat uit vier delen, die we hieronder bespreken.

Bron

De bron beschrijft waarop de productie van een gevolg gebaseerd is. In veel gevallen is dat een eerder in de keten geproduceerd gevolg. Of meer precies: een verstrekking, gedaan in een voorliggende bounded context, die als signaal is ontvangen en binnen de ‘eigen’ bounded context aanleiding gaf tot handelen. Als zo’n voorliggend gevolg ontbreekt, is de aanleiding gelegen buiten de overheidscontext, bijvoorbeeld in een handeling of melding van een burger of bedrijf.

Vragen bij het vastleggen van bron in het gevolgenjournaal

1. Wat slaan we op? Tenminste een verwijzing naar het voorliggende gevolg of de externe aanleiding, inclusief de partij die verantwoordelijk was voor productie van die aanleiding. Omdat hierbij grenzen tussen bounded contexten worden overgestoken, moeten contextoverstijgende afspraken worden gemaakt over vorm, inhoud en uitwisseling van deze verwijzing.
2. Wat doen we met bijlagen? Aanleidingen kunnen gepaard gaan met ondersteunende documenten, zoals een aanvraagformulier of een bijgevoegd bewijs. Deze bijlagen zijn niet altijd op een volledig gevolg van toepassing. Een te complexe koppelstructuur tussen bijlagen en gegevens is moeilijk te begrijpen en te onderhouden. De vraag is of zulke complexiteit altijd noodzakelijk is, of dat een eenvoudiger benadering (aparte documentopslag waarnaar voor aanleiding verwezen kan worden) volstaat.

Legitimering

Voor ieder gevolg wordt een zo gedetailleerd mogelijke verwijzing naar het wettelijk of beleidskader dat diende als grondslag voor de productie daarvan vastgelegd. Daarbij wordt ook vastgelegd hoe het legitimerende kader in de betreffende situatie is toegepast, inclusief - indien van toepassing - de motivatie waarom op basis van discretionaire bevoegdheid van een norm is afgeweken.

Verantwoordelijke

Bij ieder gevolg wordt vastgelegd welke ambtenaar of organisatieafdeling voor productie daarvan verantwoordelijk was.

Werkwijze

Voor ieder gevolg wordt een verwijzing opgenomen naar de gevolgde procedures of - bij geautomatiseerde verwerking - de versie van het gebruikte algoritme.

Tijd

In het gevolgenjournaal zien we twee soorten tijd, die hieronder besproken worden.

Systeemtijd

Voor ieder gevolg wordt het moment van vastlegging in het gevolgenjournaal vastgelegd. Dit moment heet het gevolgtijdstip en is een verschijningsvorm van systeemtijd aan de journaalkant.

Domeintijd

Als we kijken naar temporele concepten die bij gegevensopslag een rol spelen, kunnen we in het gevolg een specifieke vorm van een event herkennen. Zo’n event wordt beschreven als een ogenblikkelijk feit, ofwel iets dat in één moment plaatsvindt.

Dit temporeel atomaire karakter maakt dat het gevolg geen (geldigheids)duur heeft. In plaats daarvan kent het één door het domein bepaald moment, dat samenvalt met het moment waarop het gevolg in de echte wereld een verandering tot stand bracht. Dit moment noemen we "gebeurd op".

In veel gevallen (maar niet alle, zie toelichting hieronder) kan van het gebeurd op-moment bij een gevolg een geldig vanaf-moment in een projectie worden afgeleid. Ervan uitgaande dat we het moment van geboorte beschouwen als startpunt voor een geldige inschrijving, kan bijvoorbeeld van het gevolg persoon p1 geboren | gebeurd op 18-07-1985 de volgende projectie worden afgeleid:

Impact van feitelijk of administratief formuleren op aandachtsgebied geldigheid

• Bij feitelijke formulering is het ‘gebeurd op’-moment een logisch startpunt voor geldigheidsperiode(s) in projecties, terwijl
• bij administratieve forumlering weliswaar sprake blijft van een domeindatum, maar het ‘gebeurd op’-moment meer neigt naar het karakter van een ‘geregistreerd op’-moment.

Twijfelen

Of bij een gevolg twijfel over de feitelijke juistheid mogelijk of zinvol is, hangt af van de wijze waarop het gevolg is geformuleerd (zie toelichting hieronder). Voor zover dit wel mogelijk en zinvol is, maakt het register het mogelijk twijfel in het gevolgenjournaal te registreren.

Impact van feitelijk of administratief formuleren op aandachtsgebied zekerheid

• Bij feitelijke formulering beschrijft het gevolg iets wat buiten de context van het register is gebeurd. Dit gebeuren kan feitelijk waar, maar ook feitelijk onwaar blijken te zijn. Als we gevolgen feitelijk modelleren, lijkt het dus nodig om aan de juistheid van een gevolg te kunnen twijfelen door daaraan zekerheidskenmerken te verbinden, terwijl
• bij administratieve formulering het gevolg gaat over iets dat door registratie van gevolg zelf feitelijk waar wordt - de geboorteregistratie ontstaat immers door registratie van het bijbehorende gevolg. In dit geval ontstaat de feitelijke juistheid door registratie van het gevolg zelf, en lijkt het niet zinvol om aan de juistheid van een gevolg te kunnen twijfelen.

Onttrekking

Iedere onttrekking begint in een gevolg, tenzij de fout uitsluitend zat in de wijze waarop projecties uit het gevolgenjournaal werden afgeleid.

Los van de mate waarin een onttrekkingsgevolg aansluit bij de taal van de bounded context (zie corrigeren) beschrijft zo’n gevolg altijd de onttrekkingscontext. Die maakt achteraf reconstrueerbaar waarom en wanneer een gevolg niet langer beschikbaar is en omvat tenminste:

• een verwijzing naar het onjuiste, te onttrekken gevolg;
• het tijdstip waarop tot onttrekking is besloten (‘gebeurd op’);
• de reden voor de onttrekking, en
• een verwijzing naar het onderzoeksdossier waarin meer informatie over de aanleiding voor onttrekking terug te vinden is.

Als een onttrekking betrekking heeft op identiteitdragende kenmerken van een gevolg of projectie-element, wordt het volledige gevolg of het volledige projectie-element onttrokken. Bij niet-identiteitshoudende kenmerken kan onttrekking beperkt blijven tot die kenmerken, mits de implementatie dit technisch toelaat.

Algemene ontwerpafwegingen voor het gevolgenjournaal

Bij het ontwerpen van gevolgen in het gevolgenjournaal zijn een aantal afwegingen van belang. Welke het zwaarst wegen, verschilt per domein. De onderstaande afwegingen bieden houvast bij het maken van weloverwogen keuzes.

• Intentie: Gevolgen dienen de intentie van de observatie, het besluit of de vastlegging uit te drukken
• Negeer de afnemer als het gaat om vorm en omvang: Het domein bepaalt onafhankelijk van afnemerbehoeften de vorm en omvang van gevolgen die binnen de bounded context worden geproduceerd
• Respecteer de afnemer als het gaat om inhoud: Alle gevolgen die een bounded context produceert samen, moeten voldoende informatie vastleggen om (redelijke en realistische) afnemersbehoefte aan informatie vanuit de bounded context in te kunnen vullen
• Herkenbaar voor de business: Gevolgen worden gedefinieerd op basis van functionele (business)behoefte. Dit betekent dat ieder gevolg in het gevolgenjournaal een relatie heeft met een besluit of ander betekenisvol gebeuren uit de business
• Hergebruik: Gevolgen kunnen als bouwsteen worden hergebruikt binnen omvangrijkere gevolgen, zonder dat ze daarmee hun zelfstandig bestaansrecht verliezen

Vraagstuk: gevolgen feitelijk of administratief formuleren?

Om de intentie zo scherp mogelijk uit te drukken, stellen we de volgende richting voor:

1. Administratief voor fysieke waarnemingen: Gevolgen van fysieke waarnemingen of fysieke gebeurtenissen worden vanuit een register als administratieve gevolgen verwoord. Een gevolg "geboorte persoon p1 geregistreerd" prevaleren we boven "persoon p1 geboren". De persoon is namelijk ook geboren als dat niet in de registratie als gevolg is vastgelegd
2. Feitelijk voor registratieve beslissingen: Gevolgen die inherent, vaak juridische, consequenties hebben doordát deze zijn vastgelegd, kunnen als feitelijk worden uitgedrukt. Met "parkeervergunning pg1 vastgesteld" vastgelegd gevolg, ís deze parkeervergunning vastgesteld / besloten. Uiteraard kan een "bewijs voor parkeervergunning uitgegeven" volgen als een fysiek bewijs is uitgegeven

Bij het modelleren van gevolgen kunnen onder andere de volgende constructen worden ingezet:

• Naamgeving van de gevolgen drukt zoveel mogelijk de intentie en context uit, bijvoorbeeld in GeboorteGeregistreerd, NaamGewijzigdNaarAanleidingVanAdoptie, WozObjectOntstaatNaarAanleidingVanPerceelsplitsing

• Typering als gegeven van een gevolg kan additioneel gebruikt worden, bijvoorbeeld door een waardelijst in het veld typeGevolg op te nemen

• Hergebruik/decompositie/interfacing: een gevolg kan kenbaar maken dat het een bepaald type wijziging omvat, zodat afnemers daarop kunnen aansluiten zonder de specifieke aanleiding te hoeven kennen. Een verhuizing en een adoptie leiden allebei tot een adreswijziging - door beide gevolgen een gemeenschappelijk “adreswijziging”-contract te laten vervullen, kunnen afnemers die alleen de adreswijziging nodig hebben op beide reageren.

  In object-georiënteerde talen wordt dit gerealiseerd via interface of abstract class (inheritance en composition); in functionele talen via een trait. Het concept is ook herkenbaar in UML.

Voorbeeld – adoptie in de BRP

Een adoptie brengt doorgaans drie wijzigingen tegelijk met zich mee: een naamswijziging, een adreswijziging en een wijziging van gezag. Elk van die drie kan echter ook zelfstandig voorkomen – door een eigen naamskeuze, een verhuizing, of een rechterlijke uitspraak die niets met adoptie te maken heeft.

Door gevolgen als AdoptieGeregistreerdNaRechterlijkeBeschikking en VerhuizingGeregistreerd allebei de interface AdresGewijzigd te laten implementeren, kunnen afnemers die alleen de adreswijziging nodig hebben op beide reageren – zonder de onderliggende aanleiding te hoeven kennen. In het BRP-stelsel speelt ook een autorisatiereden mee: afnemers zonder adoptie-autorisatie mogen PersoonGeadopteerd niet ontvangen, maar wel AdresGewijzigd.

interface NaamGewijzigd {
    val nieuweGeslachtsnaam: String
}

interface AdresGewijzigd {
    val nieuwAdres: Adres
}

interface GezagGewijzigd {
    val nieuweOuders: List<Persoon>
}

data class AdoptieGeregistreerdNaRechterlijkeBeschikking(
    override val nieuweGeslachtsnaam: String,
    override val nieuwAdres: Adres,
    override val nieuweOuders: List<Persoon>,
    // ...
) : NaamGewijzigd, AdresGewijzigd, GezagGewijzigd

data class VerhuizingGeregistreerd(
    override val nieuwAdres: Adres,
    // ...
) : AdresGewijzigd

Verdieping: projecties

Betekenis en doel

Een projectie is een samenhangende en op de informatiebehoefte van afnemers toegesneden gegevensverzameling, bedoeld voor verstrekking. Waar het gevolgenjournaal nauwkeurig documenteert wat er is gebeurd, beantwoorden projecties primair vragen als “leeft persoon p1 nog?”, “wat is zijn burgerlijke staat?”, en “heeft hij gezag over p3?” Zulke vragen veronderstellen een stand (ook wel toestand of state), ofwel een beeld van de wereld dat gedurende een bepaalde periode geldig is.

Niet alle projecties beschrijven een toestand. Een notificatiebericht is daarvan een voorbeeld: het informeert een afnemer over een verandering die door registratie van een gevolg is veroorzaakt. Net als het onderliggende gevolg is zo’n bericht temporeel atomair - het beschrijft wat er is gebeurd, niet welke toestand na dat gebeuren geldig werd.

Hoe projecties technisch wordt bijgehouden is een implementatiekeuze: ze kunnen vooraf worden berekend en opgeslagen, of op het moment van bevraging op basis van de opgegeven parameters gegenereerd.

Projectieperspectief: continuant of occurrent?

Als we willen begrijpen hoe projecties eruit zien, helpt het te begrijpen hoe we data willen representeren en wat de consequenties daarvan zijn. Dat doen we door om te beginnen een onderscheid aan te brengen tussen projecties die gaan over continuants (ook wel endurants of in het Nederlands voortdurenden) en projecties van occurrents (ook wel perdurants of in het Nederlands perdurantisten of voorkomenden).

Een continuantprojectie projecteert een entiteit - de continuant - die in de tijd beschouwd kan worden. Zo’n projectie levert voor ieder moment van het bestaan (of de geldigheid) van de continuant een complete en betekenisvolle toestand op.

Niet alle continuants zijn gelijk. Sommige daarvan kunnen onder één identiteit maximaal één geldigheidscyclus doormaken (denk aan een mens). Hun bestaansperiode is continu. Daarnaast komen contiunants (zoals een huwelijk) voor die meerdere, discontinue (of onderbroken) geldigheidsperiodes kunnen kennen. Het ontstaan van een tweede (of derde, vierde etc.) geldigheidsperiode bij zo’n entiteit noemen we vaak herleven.

Een occurrentprojectie projecteert een entiteit - de occurrent - die zich in de tijd voltrekt. Zo’n projectie kan alleen compleet en betekenisvol zijn als we alle momenten die de voltrekking van de occurrent duurde samen beschouwen.

Occurrents kunnen we onderverdelen naar de tijd die voltrekking duurde. Punctuele occurrents zijn instantaan (of temporeel atomair) en voltrekken zich op één moment. Duratieve occurrents voltrekken zich gedurende een periode, die in veel gevallen kan worden opgedeeld in fases (of stages).

Wetenschappelijk achtergrond en debat

In deze handreiking noemen we continuant en occurrent omdat ze helpen geprojecteerde gegevens te begrijpen. Achter deze begrippen gaan een lange wetenschappelijke geschiedenis en veel debat schuil.

De woorden continuant en occurrent werden voor het eerst beschreven in het driedelige ‘Logic’ (1921–1924) van de Britse logicus W.E. Johnson. Via debatten over persistentie en formele ontologie, waaronder Barry Smiths’ Basic Formal Ontology, vonden ze vervolgens hun weg naar de informatica.

Over deze begrippen bestaat binnen de wetenschap veel discussie. Zo stelde James F. Allen in ‘Maintaining Knowledge about Temporal Intervals’ dat occurrents weliswaar instantaan kunnen lijken, maar dat voltrekking bij nadere beschouwing (“turning up the magnification”) toch altijd een periode met tijdsduur vraagt.

In reactie daarop (‘A critical examination of Allen’s theory of action and time’) betoogde Antony Galton dat het problematisch is om alle occurrents als interval te behandelen en dat we daarnaast ook instants moeten kunnen herkennen. Een middenpositie wordt ingenomen door Bittner et al., die in ‘Endurants and Perdurants in Directly Depicting Ontologies’ de periode waarbinnen een occurrent zich voltrekt verdelen in al dan niet instantane stages (fases).

Ook het zelfstandig bestaansrecht van continuants staat ter discussie. Zo betogen perdurantisten dat alle objecten in vier dimensies bestaan. Wat we hierboven een continuant noemden, is vanuit dit perspectief geen zelfstandige entiteit, maar slechts een instantane doorsnede van zo’n vierdimensionale occurrent.

Projectiedoel bepaalt perspectief

Of een entiteit geprojecteerd wordt als continuant of als occurrent staat los van de manier waarop we gegevens in het gevolgenjournaal of andere bron voor onze projectie hebben vastgelegd. Het projectieperspectief wordt dus niet bepaald door het vastleggingspersperspectief van het bronmateriaal, maar door de manier waarop we naar dat bronmateriaal willen kijken - en in het verlengde daarvan van de informatiebehoefte die we met een projectie willen invullen.

Dit betekent dat op basis van één set gevolgen voor de ene doelgroep continuantprojecties kunnen worden geproduceerd, terwijl voor andere afnemers projecties vanuit occurrentperspectief worden gemaakt.

Onderstaand voorbeeld illustreert hoe op basis van één set gevolgen die rondom een vergunning zijn bijgehouden projecties in continuant- én occurrentvorm kunnen worden geproduceerd. De continuantprojectie beschouwt de vergunning als entiteit waarvoor een toestand kan worden getoond. Projecteren we de vergunning als occurrent, dan krijgen we een aan de hand van ‘milestones’ geïllustreerde levenscyclus te zien.

// In het gevolgenjournaal bekende gevolgen die de levenscyclus van de vergunning hebben beïnvloed

[
  {
    "gevolgId": "ev-001",
    "gevolgType": "vergunningsaanvraag ontvangen",
    "betreft": { "type": "aanvraag", "id": "av-2004-1459" },
    "gebeurdOp": "2004-03-12"
  },
  {
    "gevolgId": "ev-002",
    "gevolgType": "vergunning verleend",
    "betreft": { "type": "vergunning", "id": "vg-2004-0815" },
    "beïnvloedt": { "type": "aanvraag", "id": "av-2004-1459" },
    "gebeurdOp": "2004-06-18"
  },
  {
    "gevolgId": "ev-003",
    "gevolgType": "vergunning ter inzage gelegd",
    "betreft": { "type": "vergunning", "id": "vg-2004-0815" },
    "gebeurdOp": "2004-06-21"
  },
  {
    "gevolgId": "ev-004",
    "gevolgType": "bezwaar ontvangen",
    "betreft": { "type": "bezwaar", "id": "bz-2004-0213" },
    "beïnvloedt": { "type": "vergunning", "id": "vg-2004-0815" },
    "gebeurdOp": "2004-06-23"
  },
  {
    "gevolgId": "ev-005",
    "gevolgType": "bezwaar afgewezen",
    "betreft": { "type": "bezwaar", "id": "bz-2004-0213" },
    "beïnvloedt": { "type": "vergunning", "id": "vg-2004-0815" },
    "gebeurdOp": "2004-07-17"
  },
  {
    "gevolgId": "ev-006",
    "gevolgType": "vergunning onherroepelijk geworden",
    "betreft": { "type": "vergunning", "id": "vg-2004-0815" },
    "gebeurdOp": "2004-08-02"
  }
]

// Vergunningaanvraag als continuant: het object met actuele toestand

// Request
{
  "resource": "vergunningen",
  "id": "vg-2004-0815",
  "presentatieperspectief": "continuant",
  "geldigOp": "2004-07-24"
}

// Response
{
  "id": "vg-2004-0815",
  "status": "verleend",
  "isOnherroepelijk": "false"
}

// Vergunningaanvraag als occurrent: gefaseerde levenscyclus

// Request
{
  "resource": "vergunningen",
  "id": "vg-2004-0815",
  "presentatieperspectief": "occurrent",
  "gebeurdVanaf": "1970-01-01",
  "gebeurdTot": "2004-07-25"
}

// Response
{
  "id": "vg-2004-0815",
  "fases": [
    { "type": "vergunning verleend", "gebeurdOp": "2004-06-18" },
    { "type": "vergunning ter inzage gelegd", "gebeurdOp": "2004-06-21" },
    { "type": "vergunning door bezwaar betwist", "gebeurdOp": "2004-06-23" },
    { "type": "betwisting vergunning door bezwaar beëindigd", "gebeurdOp": "2004-07-17" }
  ]
}

Intermezzo: van gevolg naar projectie

Een projectie is geen directe weergave van de gevolgen in het journaal — er zit altijd bewerking tussen. Bij de continuantprojectie hierboven is dat bijvoorbeeld zichtbaar in de boolean isOnherroepelijk. Die is op false gezet omdat er op het gevraagde moment nog geen gevolg “vergunning onherroepelijk geworden” was geregistreerd. Om tot een te projecteren toestand te komen, worden hier dus gevolgen geïnterpreteerd.

Ook bij een occurrentprojectie is bewerking nodig, maar die is subtieler. Omdat het gevolgenjournaal zelf al bestaat uit occurrents, zou je kunnen denken dat die in een projectie één op één overgenomen worden. De projectie in het voorbeeld hierboven wijkt niettemin subtiel van de gevolgen waarop die gebaseerd is. Dat komt door een afwijkend perspectief. Het journaal beschrijft vanuit bijhoudingsperspectief zo nauwkeurig mogelijk wat er binnen een bounded context gebeurt. Vanuit projectieperspectief is het gewenst dat gebeurde opnieuw te ordenen rond bepaalde kernconcepten.

In het voorbeeld zie je dit op twee manieren terug. Het gevolg “bezwaar ontvangen” is opgesteld het vanuit bijhoudingsperspectief relevantste concept - het bezwaar zelf. In de vergunningprojectie moet dit gevolg ‘hertaald’ worden zodat het leest als een fase in de levenscyclus van de vergunning, ergo “vergunning door bezwaar betwist”. Het gevolg “vergunningsaanvraag ontvangen” verschijnt in de projectie helemaal niet omdat de vergunning op dat moment nog niet bestond en de levenscyclus daarvan dus nog niet was begonnen.

Tijdsaspecten van projectieperspectief

In de projectievoorbeelden hierboven worden in relatie tot ‘tijd’ verschillende begrippen gebruikt. De continuantprojectie wordt bevraagd op basis van geldigheidsmomenten (met parameters als geldigOp, geldigVanaf of geldigTot), terwijl we in het request voor de occurrentprojectie een voltrekkingsperiode (met gebeurdVanaf en gebeurdTot als parameters) opgeven. Dit is geen toeval: bij projecties vanuit verschillend perspectief horen verschillende temporele dimensies.

Nota bene: systeemtijd werkt voor de in dit hoofdstuk besproken projecties op dezelfde manier en wordt hier daarom niet nader behandeld; in de paragraaf projectiesoorten komen we hier op terug voor de gevallen waar systeemtijd een afwijkende rol speelt.

Continuants: geldigheid

Het begrip geldigheidstijd (of valid time) werd in 1986 gemunt door Richard Snodgrass en Ilsoo Ahn. In hun artikel ‘Temporal Databases’ illustreren de auteurs deze temporele dimensie aan de hand van een universiteitsmedewerker (‘Merrie’) die door de tijd verschillende functies heeft.

Informatie over de veranderende functie van Merrie vinden we door aan een projectie de vraag te stellen “wat was op moment tx de functie van Merrie?” Voor september 1973 zou het antwoord ‘instructor’ luiden, terwijl het voor december van dat jaar ‘assistent professor’ zou zijn. Hoewel het artikel dit niet expliciet maakt, veronderstelt dit voorbeeld een projectie over Merrie’s functies vanuit continuantperspectief.

Occurrents: voltrekking

Bovenstaande conclusie kunnen we trekken omdat we een occurrentprojectie niet betekenisvol op de beschreven manier kunnen bevragen. Neem opnieuw de veranderende functie van Merrie, maar nu niet beschouwd vanuit een medewerker met verschillende rollen, maar als loopbaan: een gefaseerde voltrekking van opeenvolgende aanstellingen.

Stel dat je daarover vraagt: “hoe zag moment tx Merrie’s loopbaan eruit?” Dan zou voor 1 oktober 1973 het antwoord als volgt kunnen luiden: “Merrie was als instructor aangetreden, de aanstelling als assistant professor was nog niet ingegaan.” Wat hier beschreven wordt is geen toestand, maar een opsomming van op het bevragingsmoment gepasseerde en onderhanden fases.

Op basis hiervan kunnen we concluderen dat de ‘geldigheid’ van een loopbaan op 1 oktober 1973 (of een ander moment) eenvoudigweg niet bestaat. Wat wel bestaat is het feit dat een deel van de loopbaan achter de rug is - we noemen dit ‘voltrokken’ - en een ander deel nog moet komen. Dit betekent dat we occurrents niet bevragen en projecteren op basis van geldigheidstijd, maar op basis van voltrekkingstijd (of occurrence time).

Geldigheid + voltrekking = domeintijd

We hebben hierboven gezien dat continuants en occurrents ieder hun eigen tijdsdimensie kennen - geldigheidstijd voor de eerste, voltrekkingstijd voor de tweede. Dit plaatst ons voor een probleem. Want in literatuur wordt de term geldigheidstijd vaak gebruikt als generieke aanduiding voor alles wat geen systeemtijd is. Dat is een historisch gegroeide onnauwkeurigheid: geldigheidstijd is passend voor continuants, maar niet voor occurrents.

Wat geldigheidstijd en voltrekkingstijd gemeen hebben, is dat ze beide iets uitdrukken over de (fysieke, juridische of administratieve) werkelijkheid die het register beschrijft, en niet over het register zelf. Deze categorie tijdsbegrippen willen we met één begrip kunnen aanduiden. Hiervoor kiezen we het woord domeintijd. Die omvat alle vormen van tijd die niet door het register zelf worden bepaald maar door wat in het bedrijfsdomein gebeurt of geldt.

We werken tijdsaspecten technischer uit in de verdieping temporaliteit in projecties.

Projectiesoorten

Met het onderscheid tussen continuant en occurrent en de bijbehorende temporele dimensies hebben we de bouwstenen om projecties scherper te kunnen typeren. Voor welke ‘soort’ projectie is welke domeintijd relevant? Geldigheidstijd, voltrekkingstijd, of geen van beide? En binnen die dimensie: zijn meerdere geldigheidsperiodes mogelijk of niet, duurt voltrekking tijd, of gebeurt dat in één moment?

Onderstaande tabel plaatst deze categorieën op een domeintijdas. Op de andere as kunnen we dan de tijdsdimensie plaatsen die wel door het register wordt bepaald: de systeemtijd. De tabel die hierdoor ontstaat kunnen we vullen met acht projectiesoorten. Voor ieder daarvan volgt hieronder een korte typering en één of meer voorbeelden.

Nota bene: tabel en projectiesoorten gaan over projecties die in het normaal verkeer aan afnemers worden getoond. Betrouwbaar beheer en navolgbaar foutherstel maken het in vrijwel alle gevallen gewenst systeemtijd bij te houden - dus ook voor specificatiegegevens, automatische observaties en vaste waarden.

Herlevend ding

Een continuantprojectie van een entiteit die meerdere, al dan niet aansluitende geldigheidsperiodes onder dezelfde identiteit kan kennen. Tussen periodes kan de geldigheid onderbroken zijn en later weer hervatten. Voorbeeld: een huwelijk dat na ontbinding opnieuw wordt voltrokken tussen dezelfde personen.

Niet-herlevend ding

Een continuantprojectie van een entiteit die onder één identiteit één aaneengesloten geldigheidsperiode kent. Eindigt de geldigheid, dan eindigt de entiteit definitief — een tweede geldigheidsperiode onder dezelfde identiteit is niet mogelijk. Voorbeelden: een mens, een dienstverband, een vergunning.

Traject

Een occurrentprojectie van een entiteit die zich gefaseerd over een aaneengesloten periode voltrekt. Het traject heeft een aanvang, een einde en interne fases die samen de voltrekking vormen. Voorbeelden: een vergunningprocedure, een behandeltraject, een bezwaarprocedure.

Gebeurtenis

Een occurrentprojectie van een entiteit die zich op één moment in de tijd voltrekt. De gebeurtenis kent geen interne fases en is temporeel atomair. Voorbeelden: een melding, een meting, een klantcontact.

Systeemevent

Een occurrentprojectie van een gebeurtenis die uitsluitend binnen het systeem plaatsvindt en geen tegenhanger heeft in de werkelijkheid daarbuiten. Domeintijd ontbreekt; alleen systeemtijd is relevant. Voorbeelden: een logregel, een audit trail entry, een systeemmelding.

Specificatiegegeven

Een continuantprojectie van een entiteit met beperkte veranderlijkheid die de kaders beschrijft waarbinnen andere, meer volatiele gegevens zich bewegen. Daarom hoeft hierover bijgehouden registratiehistorie in projecties doorgaans niet te worden getoond. Voorbeelden: een zaaktype, een producten- en dienstencatalogus, een classificatie.

Automatische observatie

Een occurrentprojectie waarbij vastlegging zonder menselijke tussenkomst plaatsvindt op het moment van plaatsvinden, waardoor registratiemoment en voltrekkingsmoment per definitie samenvallen. Voorbeelden: een sensormeting, een GPS-track, een automatische transactie.

Vaste waarde

Een continuantprojectie zonder tijdsdimensie. De waarde staat onveranderlijk vast en kent geen geldigheids- of registratiehistorie. Voorbeelden: een landcode, een geslachtsaanduiding, een natuurconstante.

De herhaalbare vraag

Zoals eerder in dit document genoemd is het een belangrijke eis van een betrouwbaar register om, zoveel als mogelijk, de herhaalbare vraag te kunnen beantwoorden. Een afnemer moet, nadat deze op tijdstip T1 een gegeven heeft opgevraagd, op tijdstip T2 nog steeds de vraag kunnen stellen wat dit gegeven op tijdstip T1 was. Een betrouwbaar register dient dit te kunnen nadat:

1. Er nieuwe gevolgen zijn toegevoegd aan de registratie.
2. Een gegeven hersteld is doordat het geldigheidstijdvak is veranderd vanwege een foutieve registratie.
3. Een softwarebug in de opvraging is hersteld waardoor de initiële opvraging fout was.

Criterium 1 en 2 introduceren bitemporaliteit in de registratie. Criterium 3 vereist dat er mechanismen zijn die het mogelijk maken softwareaanpassingen te doen met behoud van de eerdere gegevensrepresentatie.

Inherente beperkingen aan de herhaalbare vraag

Elk register loopt tegen inherente beperkingen aan. Zowel geldigheids- als gevolgtijdstippen hebben te maken met eventual consistency: er zit altijd tijd tussen het begin van een registratie en het einde daarvan, en er zit altijd tijd tussen een opvraging en de zichtbaarheid van deze gegevens voor de afnemer. Dit betekent dat een afnemer altijd in potentie naar verouderde informatie kijkt.

Daarnaast heeft een register meestal niet de volledige controle over de verstrekking van informatie. Beweringen verlaten op een bepaald moment het register om elders te worden gepresenteerd — in een browser, een API-response, of een ander systeem dat het register niet kent.

Herhaalbaarheid van opvraging is dus hoogstens te behalen tot op het niveau van de gegevensrepresentatie net voordat deze het systeem verlaat. Hoe met deze beperkingen om te gaan is een ontwerpoverweging; zie eventual consistency als ontwerpoverweging.

Terugmelden

Terugmeldingen hebben altijd betrekking op een projectie. De afnemer meldt dat hij twijfelt aan de juistheid van (een deel van) die projectie.

Omdat projecties over uiteenlopende samenstellingen van gegevens kunnen gaan en de aard van geconstateerde onjuistheden sterk kan verschillen, kan een terugmelding vele vormen aannemen. Daarbij past geen beperkend ‘terugmeldformulier’, maar (vorm)vrijheid en veel ruimte voor toelichting in vrije tekst.

Als een bronhouder regelmatig terugmeldingen van dezelfde strekking ontvangt, kan hij overwegen daarvoor een specifieke, meer gestructureerde interface aan te bieden. Dit verlaagt de drempel voor de terugmelder en maakt de verwerking aan de kant van de bronhouder efficiënter.

Een terugmelding bevat in ieder geval:

• Verwijzing naar de betreffende gegevens. De terugmelder geeft aan op welke projectie of welk onderdeel daarvan de melding betrekking heeft. Hoe die verwijzing er precies uitziet, is afhankelijk van hoe projecties identificeerbaar zijn gemaakt - bijvoorbeeld via een uniek kenmerk van de verstrekking of een combinatie van subject en tijdstip
• Toelichting. De terugmelder beschrijft in vrije tekst wat hij als onjuist beschouwt en waarom. Dit biedt de bronhouder de context die nodig is om het onderzoek gericht te kunnen starten.
• Contactgegevens van de terugmelder. Zodat de bronhouder, indien het onderzoek daarom vraagt, contact kan opnemen voor nadere toelichting of terugkoppeling.

Open vragen

• Terugmelden is binnen het stelsel voor basisregistraties een voorwaarde voor afwijken van gegevens in de bron. Zouden terugmeldende afnemers dan voor eigen gebruik en hangende een onderzoek hun eigen, vermoedelijk juistere ‘alternatieve’ gegevens in het register moeten kunnen zetten?
• Hoe wijzen we gegevens waarover we terugmelden voor de bronhouder (historisch) onderscheidbaar aan?

Onderzoeken

Onderzoek naar aanleiding van een terugmelding vindt plaats buiten het register en leidt niet tot nieuwe projecties. Wel kan uit onderzoek blijken dat bij vermoedelijk onjuiste projecties indicaties van verminderde zekerheid over de juistheid moeten worden aangebracht.

Corrigeren

In de meeste gevallen is een verstrekking foutief omdat één of meerdere gevolgen die de basis vormen van deze projectie foutief waren. Het corrigeren van een dergelijke verstrekking begint dan met correctiegevolgen in het gevolgenjournaal. Een correctiegevolg bevat de gevolgen ‘hoe ze hadden moeten zijn’, en op basis van deze subgevolgen kan een projectie hersteld worden. Er wordt bepaald vanaf welk moment een bestaande projectie niet langer geldig is. Die projectie krijgt daarna een vervallen op-indicatie, waarmee de verstrekking voor actief gebruik wordt afgesloten. En daarnaast worden nieuwe projecties gemaakt, die met terugwerkende kracht de foutieve projecties bovenschrijven. Bovenschrijven betekent hierbij dat bestaande projectie-elementen behouden blijven en nieuwe elementen ernaast worden geplaatst met een later systeemtijdstip. Het register overschrijft nooit; het schrijft alleen boven, als temporele consequentie van het append-only-patroon.

Het is ook mogelijk dat uit onderzoek blijkt dat de oorspronkelijk vastgelegde gevolgen correct waren, en dat de fout hem in de afleiding van de projectie zit. Een dergelijke softwarefout zal hersteld moeten worden, waarna een volledige of selectieve replay gedaan moet worden: Ook in dit scenario moet bepaald worden vanaf welk moment een bestaande foutieve toestand niet langer geldig is, en dat deze moet vervallen. Foutieve toestanden worden geïdentificeerd en opnieuw opgebouwd, waarna ze toegevoegd worden aan de projecties en de oude toestand bovenschrijven.

Herkomst

Omdat projecties direct worden afgeleid uit gevolgen in het gevolgenjournaal, zijn herkomstmetadata aan voor projecties beknopter van omvang dan aan de journaalkant. De voornaamste verantwoording ligt immers al besloten in de gevolgen waarop een projectie is gebaseerd.

Bron

De aanleiding verwijst naar het gevolg of de gevolgen die als basis dienden voor de productie van de projectie. Daarmee is de herkomst van een projectie altijd herleidbaar naar het gevolgenjournaal.

Legitimering

Voor zover van toepassing wordt een verwijzing vastgelegd naar het wettelijk of beleidskader dat diende als grondslag voor de productie van de projectie - bijvoorbeeld als regelgeving voorschrijft welke gegevens aan welke afnemers verstrekt mogen of moeten worden.

Verantwoordelijke

Bij ieder projectie-element wordt vastgelegd welke ambtenaar of organisatieafdeling voor productie daarvan verantwoordelijk was.

Werkwijze

Het projectie-element omvat een verwijzing naar het algoritme of de algoritmes die zijn gebruikt om van één of meer gevolgen een projectie af te leiden, inclusief de versie daarvan. Zo is achteraf reconstrueerbaar op welke manier de projectie tot stand is gekomen.

Registratie

Bij iedere concrete verstrekking kan het projectietijdstip — het systeemtijdstip waarop een projectie-element beschikbaar is gekomen — worden meegeleverd. Of dat wenselijk is, hangt af van de situatie. Bij een vraag naar de actuele stand is dit tijdstip vaak niet relevant. In andere gevallen kan het meesturen ervan juist ongewenst zijn, omdat het informatie kan onthullen die niet met iedereen gedeeld mag worden, zoals het feit dat een correctie heeft plaatsgevonden.

Geldigheid

Bij projecties die zijn opgebouwd uit meerdere gevolgen, is het belangrijk onderscheid te maken tussen de geldigheidsdatum van de projectie zelf en de domeindatums van de gegevens daarbinnen.

De geldigheidsdatum van een projectie geeft aan vanaf welk moment deze projectie in deze vorm als ‘juist’ of ‘waar’ beschouwd wordt. Die datum zegt (dus) niets over de ouderdom van in de projectie betrokken entiteiten of andere daarin opgenomen gegevens.

Neem als voorbeeld de volgende gevolgen:

• woz-object w1 ontstaan | gebeurd op 15-08-1994
• belanghebbende bij woz-object w1 is p1 | gebeurd op 23-08-1994
• belanghebbende bij woz-object w1 is p2 | gebeurd op 19-10-2009
• belanghebbende bij woz-object w1 is p3 | gebeurd op 07-03-2023

Het WOZ-object bestaat al sinds 15-08-1994, maar de projectie is voor het laatst bijgewerkt naar aanleiding van het gevolg van 07-03-2023. Die datum markeert dus niet het ontstaan van het object, maar het meest recente domeinmoment dat de huidige vorm van de projectie heeft bepaald.

Zonder die toelichting riskeert een afnemer de datum verkeerd te interpreteren. Uit de projectie moet de betekenis daarom voldoende duidelijk blijken - bijvoorbeeld door de geldig vanaf-datum expliciet aan de projectie te koppelen (zie het voorbeeld hieronder), of door aan te geven dat die datum de laatste relevante wijziging in het domein betreft.

projectie l1
  geldig vanaf 07-03-2023
  woz-object w1
    eerste registratie 15-08-1994
    belanghebbenden
      p1
        start belang 23-08-1994
        einde belang 18-10-2009
      p2
        start belang 19-10-2009
        einde belang 06-03-2023
      p3
        start belang 07-03-2023

Zekerheid

Zekerheidsaanduidingen zijn in de eerste plaats relevant voor afnemers. Zekerheid moet daarom zichtbaar zijn in projecties.

Omdat onzekerheid diep kan doorwerken in ketens, is het niet altijd voldoende alleen de zekerheid van een projectie als geheel aan te geven. Een daartoe geautoriseerde afnemer moet ook kunnen zien welk onderliggend gevolg de bron van twijfel is, zodat hij kan beoordelen in hoeverre zijn eigen verwerking daarop steunt en hoe hij daarmee wil omgaan.

Afhankelijk van de situatie kan een afnemer er bijvoorbeeld voor kiezen een bedrijfsregel situationeel buiten werking te stellen, onzekerheid door te geven aan zijn eigen afnemers, of processen die op de gegevens steunen expliciet te laten waarschuwen wanneer zij onzekere gegevens tegenkomen.

Onttrekking

Of een onttrekking ingrijpt in het gevolgenjournaal, projecties, of beide, hangt af van waar de fout zat. Zat deze fout uitsluitend in de wijze waarop projecties uit het gevolgenjournaal werden afgeleid - en niet in de gevolgen zelf - dan volstaat het de afleidingswijze te corrigeren en nieuwe projecties te produceren.

In alle gevallen resulteert een onttrekking in opname van een vervallen op-moment (zie ook corrigeren) bij de door de onttrekking geraakte projecties. Daarmee wordt de projectie voor actief gebruik afgesloten, zonder dat de oorspronkelijke vastlegging verdwijnt. De onttrokken projectie blijft om de herhaalbare vraag te waarborgen technisch behouden. Die is daarna echter alleen onder specifieke voorwaarden - bijvoorbeeld voor juridisch of historisch onderzoek - toegankelijk.

Als de onttrekking betrekking heeft op identiteitsdragende kenmerken van een projectie, wordt de volledige projectie onttrokken. Bij niet-identiteitsdragende kenmerken kan onttrekking beperkt blijven tot die kenmerken, mits de implementatie dit technisch toelaat.

Resultaat voor onttrokken gegevens moet in normaal verkeer hetzelfde resultaat zijn als bevragingen van niet-bestaande gegevens.

Ontwerpafwegingen

Temporaliteit

Een belangrijke factor voor een projectie is de keuze voor wat betreft temporaliteit. Voor het kunnen beantwoorden van de herhaalbare vraag is bitemporaliteit een eis: Als ingegrepen wordt op de tijdlijn, bijvoorbeeld als gevolg van een correctie, dient de projectie nog steeds de oorspronkelijke toestand te kunnen reproduceren.

Bitemporaliteit brengt op zichzelf echter complexiteit met zich mee die niet in alle gevallen nodig is. Wanneer een herhaalbare vraag kunnen stellen minder of niet van belang is, zou een specifieke temporele projectie op de geldigheidstijdlijn of alleen een actuele toestandsprojectie ook kunnen voldoen.

Een implementatiegerichte uitleg van verschillende vormen van temporaliteit in projecties is hier te vinden.

Eventual consistency als ontwerpoverweging

Tussen het vastleggen van een gevolg in het gevolgenjournaal en de zichtbaarheid van het resultaat in een projectie zit verwerkingstijd. Bij synchrone verwerking is die verwaarloosbaar; bij asynchrone of gedistribueerde architectuur kan het venster significant zijn. Gedurende dat venster kijkt een afnemer naar een projectie die het meest recente gevolg nog niet weerspiegelt.

Deze eventual consistency gaat uitsluitend over tijdigheid, niet over logische consistentie. Gevolgen zijn er juist op gericht om een eenduidige handeling als één samenhangend geheel vast te leggen, en ondersteunen daarmee de logische consistentie van het gevolgenjournaal. Een projectie die het meest recente gevolg nog niet weerspiegelt, is dus niet tegenstrijdig met wat al is vastgelegd — de informatie is alleen nog niet doorgekomen.

Dit is geen fout maar een eigenschap van de architectuur: gevolg en projectie leven in gescheiden stores, elk met een eigen systeemtijdstip. De inherente beperkingen aan de herhaalbare vraag benoemen dit als grens van herhaalbaarheid; hier benoemen we het als ontwerpkeuze. Bij het ontwerp van een projectie moet worden afgewogen hoeveel verwerkingstijd acceptabel is en welke consequenties dat heeft voor de garanties die aan afnemers worden geboden.

Query-complexiteit versus query-flexibiliteit

De keuze van gegevensrepresentatie van een projectie en de gewenste informatie die een afnemer blieft bepaalt de complexiteit van de (database)query die gedaan moet worden om in een informatiebehoefte te voorzien. In het voorgestelde patroon, waarin we commando’s, gevolgen en projecties van elkaar scheiden, hebben we niet meer de ‘ballast’ van de commandokant, en kunnen we onze projecties specifieker optimaliseren voor de afnemer(s).

Hier zijn echter nog steeds afwegingen in te maken. Een projectie kan gebouwd worden op een manier dat de payload response van een query as is (in bijvoorbeeld een json- of xml-structuur) opgeslagen wordt in de database. We noemen dit de bitemporele opslag van payloads. Deze wijze van persisteren heeft een aantal voordelen:

1. Dit is de best mogelijke manier om de herhaalbare vraag te kunnen beantwoorden: De payload wordt as-is opgeslagen, en (later) veranderende code beïnvloedt deze payload niet.
2. Omdat de structuur van het bericht vast ligt, ook nadat er codewijzigingen gedaan worden, kan er in terugmeldingen en onderzoeken via bijvoorbeeld xpath of jsonpath hard verwezen worden naar entiteiten of velden waarover getwijfeld wordt.
3. De (database) opvraging is eenvoudig: Op basis van tijdstippen en een index dient een payload opgezocht te worden. Dit voorkomt grotendeels het verstrekken van foutieve informatie als gevolg van foutief geïmplementeerde queries.

Zeker in combinatie met bitemporaliteit zien wij de opslag van payloads als een goede keuze voor wat betreft informatieverstrekking. Bitemporaliteit kan, in combinatie met bijvoorbeeld ingewikkelde correcties, zeer ingewikkelde situaties opleveren die zelfs voor experts moeilijk te doorgronden zijn. Het feit dat de query eenvoudig is en de payload statisch is bij een bitemporele payloadstore, maakt dat deze projectievorm uitermate robuust is voor het beantwoorden van de herhaalbare vraag.

De opslag van payloads heeft echter ook nadelen: Omdat de datastructuur zo rigide vast ligt kun je moeilijker, of niet, meerdere soorten vragen beantwoorden met dezelfde projectie. Ook leent deze vorm van opslag zich minder voor joins (het combineren van verschillende payloads/entiteiten). Dit alles maakt deze structuur minder flexibel, en dit dwingt je tot het maken van veel hele afnemerspecifieke projecties.

Het bitemporele tabel-model kan naargelang behoefte dan een goede keuze zijn. Een relationeel model, en zeker een bitemporeel relationeel model, is veel flexibeler in het kunnen beantwoorden van allerhande soorten vragen. De aard van de datarepresentatie maakt echter wel de queries en de mapping naar de doelstructuur van de payload complexer, wat het garanderen van herhaalbaarheid van vragen doet afnemen.

Betrouwbare modellen versus onbetrouwbare realiteit

Een goed datamodel beschrijft structuren, entiteiten en properties van een domein. Een huisnummer is een getal, terwijl een adres een straatnaam bevat als string met een maximaal aantal karakters. Deze eigenschappen worden idealiter goed gevalideerd aan de commandokant, en door dat te doen kun je duidelijke contracten afspreken met je afnemers over wat voor data je verstrekt en in welke vorm. Dergelijke modellen bepalen databasestructuren en beperkingen voor wat betreft gegevensopslag.

De realiteit is echter vaak weerbarstig: Ooit verkeerd geïmplementeerde validaties, oude data uit migraties of veranderingen in het datamodel naar verloop van tijd kunnen er in veel gevallen voor zorgen dat de data die je hebt niet altijd voldoet aan het voorgeschreven gegevensmodel. Huisnummers met letters, te lange straatnamen… Als je gebonden bent aan het principe van het kunnen beantwoorden van de herhaalbare vraag zal deze data altijd foutief blijven.

Een relationeel model biedt duidelijkheid over het datamodel, maar is minder flexibel als het gaat om data die niet aan dit model voldoet. Er moet altijd een keuze gemaakt worden: voor zeldzame uitzonderingen dient het model aangepast te worden, of deze uitzonderingen kunnen niet verwerkt worden. Hetzelfde probleem geldt vaak voor berichtvalidaties via bijvoorbeeld XSD’s.

De consequenties van bijvoorbeeld een verhuizing niet doorgeven omdat een straatnaam te lang bevonden wordt zien wij als zeer onwenselijk. Afhankelijk van de datakwaliteit kan het dan een betere keuze zijn om data-opslag en berichtverkeer flexibeler te maken zodat afwijkingen van het datamodel wel opgeslagen en gecommuniceerd kunnen worden. Richting een afnemer kan het dan wenselijk zijn deze communicatie te doen met een extra melding: “in dit bericht voldoen we niet aan het datamodel”.

Generaliseerbaar versus specifieke implementatie

Varianten

Hieronder volgt een niet-uitputtende lijst van varianten van projecties die gebruikt kunnen worden. Elke projectievariant heeft voor- en nadelen die, afhankelijk van de use case, sterker of minder sterk gelden. Het is niet ons doel om te stellen welk van deze varianten de voorkeur geniet. Wel willen we voor- en nadelen van projectievarianten benoemen.

Transactionaliteit

Een gevolg legt één besluit of gebeuren vast. Dit besluit kan bestaan uit deelbesluiten of anderszins opdeelbare elementen, maar uiteindelijk betreft het nog steeds één besluit, dat (voor zover relevant voor de projectie) in zijn geheel wel of niet verwerkt dient te worden in een projectie, wat in databasetermen betekent dat een gevolg altijd in precies één databasetransactie verwerkt dient te worden. Het verwerken van een door de business erkend gevolg in meerdere (database)transacties kan er namelijk toe leiden dat datacorruptie optreedt: als een gevolg in twee transacties verwerkt wordt, zou de tweede transactie mis kunnen gaan, waarbij een ongeldige situatie ontstaat.

De implementatie-uitdaging bij projecties

Om van gevolg te komen tot een opvraagbare projectie hebben we een aantal transities nodig, waarbij meestal een vorm van opslag een tussenvorm is tussen het gevolg en wat de afnemer uiteindelijk op zijn scherm ziet. Een simpele flow chart van dit proces ziet er als volgt uit:

Uitgaande van deze architectuur hebben we in feite twee implementatie-uitdagingen:

1. Hoe vertalen we de gevolgen naar een opgeslagen projectierepresentatie?
2. Hoe vertalen we de opgeslagen projectierepresentatie (herhaalbaar) naar een leverbaar artefact?

Bij beide uitdagingen hebben we een implementatievorm nodig die robuust te bouwen is zodat deze een lange periode, mogelijk tientallen jaren, betrouwbaar herhaalbare vragen kan beantwoorden. En in die periode hebben we te maken met software die continue blijft evolueren, waar regelmatig (wekelijks, of zelfs dagelijks) nieuwe features aan toegevoegd worden, en de technologie je om de zoveel jaar stuurt naar software- of datamigraties.

Zowel een gevolgenjournaal als een bitemporele store bewaart data (grotendeels) append only: terwijl software veranderlijk is, blijft onze data behoorlijk statisch. We hebben dus vooral te maken met de veranderlijkheid van software. Hoe garandeer je dan de herhaalbare vraag? Bugs in deze software zijn ook onvermijdelijk. Hoe garandeer je hetzelfde (corrupte) antwoord na het oplossen van een bug? Zoals eerder benoemd kent herhaalbaarheid zijn grenzen, maar welke implementatiekeuzes het beste bij dit vraagstuk?

Door bij het opslaan van de transformatie van de gevolgen in de projectiestore te streven naar standaardisatie kunnen we fouten voorkomen: Een bitemporele store kunnen bijwerken met standaardoperaties, onafhankelijk van het soort gevolg, en aan de andere kant willen we herhaalbare, simpele queries hebben zodat de kans op softwarefouten bij het beantwoorden van de herhaalbare vraag zo klein mogelijk is. In het conceptueel registermodel worden Standaardoperaties voor het opbouwen van een projectie reeds besproken, wat implementatietechnisch is uitgewerkt in de verdieping van het bijwerken van projecties. Als elke projectie en elk gevolg afgehandeld wordt door een reeds eerder geïmplementeerde functie verkleint dat de fout op softwarefouten. Als we de transitie van gevolg naar projectie zoveel als mogelijk doen aan de ‘linkerkant’, kunnen we beter herhaalbaar leveren: Ook de meeste softwarefouten ‘persisteren’.

Aan de rechter kant van onze store kunnen we streven naar ‘zo min mogelijk’ software voor de verstrekking van ons product. Als opvragingen uit onze store eenvoudig zijn, is de kans dat daar softwarefouten in zitten kleiner. Onze architectuur ziet er dan als volgt uit:

Het vereenvoudigen van de opvragingssoftware is niet zonder prijs. Er zal per projectie afgewogen moeten welke criteria het zwaarst wegen. Het volgende hoofdstuk gaat daarover.

Implementeringsvormen per projectie-archetype

Het conceptueel registermodel onderscheidt vijf archetypische projecties: aan de toestandskant de actueel geldige toestand, in domein geldige historische toestanden en alle historische toestanden, aan de gebeurenkant het onderschreven verloop en het volledig verloop. Deze archetypen zeggen wat een projectie bevat; ze zeggen niet hoe je die bouwt. Per archetype zijn meerdere implementeringsvormen mogelijk, die langs twee assen variëren:

• Temporaliteit: alleen de actuele stand, domeintijd zonder systeemtijd, of domeintijd en systeemtijd samen (bitemporeel).
• Opslag- en leveringsvorm: rijen in relationele tabellen, payloads, een hybride vorm van cellen en payload, of een stream die het register zelf uitgeeft.

Dit noemen we in dit document overigens geen ‘soorten’; die term laten we voor de acht projectiesoorten hierboven, die gaan over het perspectief op de entiteit en niet over de bouwvorm van de projectie.

Dit hoofdstuk is een overzicht van de implementatievormen per archetype. De afwegingen tussen de vormen staan in de ontwerpafwegingen hierboven; de beslisboom hieronder leidt van de ontwerpvraag naar een van deze vormen.

Actueel geldige toestand

Voor de afnemer die alleen de stand van nu nodig heeft, komen twee vormen in aanmerking:

• Actuele tabellen: één toestand per entiteit die bij elke nieuwe toestand wordt overschreven. De eenvoudigste en snelste vorm; historie ontbreekt volledig. Deze vorm kan volledig relationeel gemaakt worden.
• Actuele payload: een payload per entiteit, eveneens herschreven bij elke nieuwe toestand.

Geen van deze vormen kan de herhaalbare vraag beantwoorden: een correctie in de domeintijd schrijft het verleden stilzwijgend over en het eerdere antwoord is weg.

In domein geldige historische toestanden

Wie enkel vragen over de domeinhistorie wil beantwoorden – “wat gold er op moment t?” – legt geldigheidsperiodes vast:

• Temporele tabellen: per rij een geldigVanaf- en geldigTot-waarde, met bij elke bijhouding een gesloten oud-periode en een nieuw-op-volg-periode. Vragen naar wat er toen gold zijn flexibel te beantwoorden; vragen naar wat het register toen onderschreef niet, want een correctie met terugwerkende kracht herschrijft de historie.
• Temporele payloads: payloads per geldigheidsperiode, in dezelfde hoedanigheid als hierboven, maar dan per geldigheidsmoment bewaard.

Deze vorm is passend zolang het antwoord op “wat gold er?” mag meebewegen met wat het register op dit moment voor juist houdt.

Alle historische toestanden

Dit archetype beantwoordt zowel “wat gold er?” als “wat onderschreef het register toen?”, en is per definitie bitemporeel. De keuze uit de beslisboom over opslagvorm komt hier op neer:

• Bitemporeel tabel model (zie bitemporele relationele databases): alle gegevens in cellen, geldigheid en registratie naast elkaar. Maximale query-flexibiliteit; herhaalbaarheid leunt dan voor een (groot) deel op query’s en code die over de jaren hetzelfde gedrag moeten blijven vertonen.
• Bitemporele opslag van payloads (zie de bitemporele payloadstore): per toestandsprojectie-element wordt de payload zoals deze verstrekt kan worden, vastgelegd, per geldigheids- en systeemtijdstippen. De query wordt eenvoudig en reduceert tot het opzoeken van één payload op basis van id en tijdstippen; de prijs is een eigen projectie per informatievraag.
• Hybride oplossing: opslag van payloads, maar dan met extra cellen om in queries te kunnen filteren en te aggregeren.

Volledig verloop

Het volledig verloop bevat ook de elementen die het register ooit onderschreef maar inmiddels niet meer. Dit verloop kan op twee verschillende manieren verstrekt worden:

• Als continue stroom van notificaties: elk gevolg (of een subset daarvan) leidt tot één of meerdere notificaties die direct aan afnemers geleverd wordt.
• Als opvraagbare reeks per entiteit of entiteiten.

Omdat al het gebeuren gecommuniceerd wordt inclusief correcties levert deze wijze van leveren een bitemporeel beeld van de registratie.

Deze vorm lijkt het sterkst op het gevolgenjournaal zelf – en is het toch niet. Het journaal beschrijft vanuit bijhoudingsperspectief wat er binnen de bounded context gebeurde; een projectie vertaalt die naar een afgeleid gebeuren waar de afnemer naar kijkt, zoals het intermezzo ‘van gevolg naar projectie’ bij het projectieperspectief hierboven illustreert.

Onderschreven verloop

Het onderschreven verloop lijkt qua vorm sterk op het volledige verloop, en dus ook op het gevolgenjournaal, maar is dit niet. De vorm is hetzelfde, maar de inhoud niet. Niet langer onderschreven gevolgen worden gefilterd, correcties voegen nieuwe gebeuren toe. Het onderschreven verloop is dus expliciet een gebeuren-projectie.

Het verloop van gebeurenprojectie-elementen die het register nu onderschrijft kan je niet streaming leveren, enkel op verzoek (per entiteit of entiteiten). Indien er behoefte is aan herhaalbaarheid voor deze vraag dienen deze onderschreven gebeuren-projecties bitemporeel vastgelegd te worden bij elk gevolg dat met terugwerkende kracht werkt.

Beslisboom: perspectief, temporaliteit en opslagvorm

Nu we verschillende implementatievormen en hun kenmerken beschreven hebben is het zaak om te weten welke variant we onder welke omstandigheden zouden kiezen. Om hierbij te helpen hebben we een ‘beslisboom’ geformuleerd, die leidt tot een projectiekeuze.

Een dergelijke boom heet een beslisboom, maar ook hier geldt dat wij vanuit uit betrouwbare bron niet alle domeinspecifieke context mee kunnen wegen. Zie deze boom als een hulpmiddel om tot een keuze te komen en niet meer dan dat.

Beslisboom: welke projectievorm kies ik?

Boom 2: bitemporele toestandsprojectie

Boom 3: opvragen van gebeurenprojectie

Begrippenoverzicht

kernconcepten — Core concepts cluster

Cluster bounded contextmodel — Bounded context model cluster

Cluster commando’s — Command cluster

Cluster gevolgen — Effects cluster

Deze archetypen zijn uitgewerkt in de verdieping.

Cluster betrouwbaarheidsaspecten — Reliability aspects cluster

Cluster projecties — Projections cluster

Cluster leveren — Deliveries cluster

Cluster betwisten — Contestations cluster

Cluster vernietigen — Data destruction cluster