Het projecteren van snapshots

Zoals hierboven opgemerkt dienen de resultaten van queries voor afnemers als bron van waarheid. Een betrouwbaar register dient met deze 'bron' dan ook zorgvuldig om te gaan, waarbij herhaalbaarheid een belangrijk criterium is. Een afnemer moet, nadat deze op tijdstip A een gegeven opgevraagd heeft, op tijdstip B nog steeds de vraag kunnen stellen wat dit gegeven op tijdstip A was. Een betrouwbaar register dient dit te kunnen nadat:

Er nieuwe gebeurtenissen plaatsgevonden hebben (nieuwe snapshots zijn toegevoegd).
Dit gegeven hersteld is (het geldigheidstijdvak veranderd is) vanwege een foutieve registratie.
Een softwarebug in de opvraging hersteld is waardoor de initiele 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 eerdere gegevensrepresentatie.

Inherente beperkingen aan herhaalbaarheid

Voordat we hierop inzoomen dient opgemerkt te worden dat elke registratie tegen inherente beperkingen aanloopt. Zowel geldigheids- als gevolgtijdstippen hebben te maken met eventual consistency: Er zit altijd tijd tussen de 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 registratie (meestal) niet de volledige controle over de aflevering van informatie. Entiteiten 'verlaten' op een bepaald moment de registratie om bijvoorbeeld gerepresenteerd te worden op een webpagina in een door anderen gebouwde browser (op bijvoorbeeld een zwart wit scherm van 320x240 in een OS die alleen Chinese karakters kan representeren, om een extreem voorbeeld te geven).

Herhaalbaarheid van opvraging is dus hoogstens te behalen tot op het niveau van de gegevensrepresentatie net voordat deze het systeem 'verlaat'.

Herstel van een registratie

Binnen het event sourcing paradigma is een aanpassing van een gevolg niet mogelijk: het herstel van fouten zal gerealiseerd moeten worden door nieuwe (herstel) gevolgen te produceren. Deze herstelwijze voorziet zowel in het herstellen van fouten van instanties of medewerkers, als het corrigeren van softwarebugs die geleid hebben tot verkeerde registratie.

Snapshots

Elke keer als een gevolg afgehandeld wordt door een projector ontstaan er 1 of meerdere nieuwe snapshots. Door deze snapshots, net als de (business)gevolgen, als event vast te leggen, ontstaat een append-only eventstream van snapshots, waarbij elke snapshot de state van een (of meerdere) entiteit(en) vastlegt op een geldigheidstijdstip, gevolgtijdstip en (een bij benadering, zie boven) projectietijdstip. Dit biedt een afnemer de mogelijkheid om queries uit te voeren en te 'tijdreizen' over deze 3 assen.

Softwarefouten in de projectie kunnen ook, met behoud van eerder fout geproduceerde snapshots, hersteld worden, voor zover deze niet gaan over de daadwerkelijke ontsluiting van deze snapshots. Deze beperking is (meestal) klein; omdat deze ontsluiting relatief eenvoudige software is of zou moeten zijn.