Herstel
In dit document worden een aantal wijzen van herstel beschreven binnen een event sourcing paradigma, met de voordelen en nadelen.
Huidige denkrichting: Voor veel voorkomende gevallen oplossing 1, als achtervang oplossing 3.
1. Specifieke commands en events
Elke mogelijke door de business erkend herstelactie wordt als eigen command en daarop volgende events gebouwd.
Voordelen:
- Expliciet en gestructureerd vastgelegd wat er hersteld is (en waarom).
Nadelen:
- Voor elk hersteltype moet software gebouwd worden.
Implementatie
Elk specifieke herstelevent moet een specifieke situatie, een collectie van eerdere gevolgen, expliciet herstellen. Dit moet ook als zodanig vastgelegd en gevalideerd worden. Met herstel bovenschrijf je altijd een eerder tijdvak: het moet dus heel duidelijk zijn welk tijdvak je bovenschrijft.
Minimale implementatie
Er zijn een aantal scenario's waarin deze wijze van implementatie min of meer vereist is:
- Verandering van identificerende gegevens
- Verschuiving van tijdstippen
- (Belangrijke) degistratie
2. Herstel via 'subcommands' ('de Kadaster-Koers methode')
Herstel wordt als generiek command geïmplementeerd, maar wordt aan de commandkant opgesplitst in subcommando's die reguliere businesscommando's representeren.
Voorbeeld: Er is een overdracht geweest van A naar B. Later blijkt echter dat de overdracht van A naar C had moeten plaatsvinden. Het herstelcommando bevat een subcommando 'overdracht', dat het systeem instrueert om het belang over te dragen van B naar C.
Voordelen:
- Het aantal herstelmogelijkheden bestaat uit je gehele scala aan 'reguliere' commando's.
- Hergebruik van validatieregels van 'reguliere' commando's is mogelijk.
Nadelen:
- Vanwege de validatieregels is het moeilijker voor medewerkers de gehele tijdlijn te herstellen (en wordt bij Koers vaak gekozen voor herstel van de actuele situatie).
- De oorspronkelijk bedoelde mutatie (de transactie) is in veel gevallen niet herleidbaar.
- Wat er precies hersteld is en waarom is vaak moeilijk te herleiden.
- Meerdere events samen vormen het herstel, met als gevolg dat in de event processing voor 1 herstelactie meerdere snapshots geproduceerd worden, waarbij er tijdvakken 'deels hersteld' ontstaan.
3. Herstel via 'subevents'
Herstel wordt uitgevoerd door 1 herstel-event toe te voegen dat 1 of meerdere reguliere events als ' sub-events' bevat. Deze sub-events dienen de eerder geproduceerde events te bovenschrijven. In feite teken je vanaf het aangegeven geldigheidstijdstip een nieuwe tijdlijn waarin je aangeeft hoe het had moeten zijn.
In het voorbeeld van de foute overdracht van A naar B, produceer je 1 herstel-event, die een subevent overdracht bevat waarin staat dat het (op datzelfde moment) een overdracht van A naar C is.
Voordelen:
- Elke tijdlijn kan bovenschreven (append only) worden met nieuwe events.
- De oorspronkelijk bedoelde mutaties zijn duidelijk herleidbaar.
- Herstel kan als 1 event vastgelegd worden en als 1 databasetransactie verwerkt worden in projecties. 1 registratietijdstip en 1 beschikbaarheidstijdstip voor het hele herstel dus.
Nadelen:
- Validatie van herstelcommando is ingewikkeld.
- Wat er precies hersteld is en waarom is moeilijk te herleiden.
- In projecties leiden sub-events tot extra complexiteit in de audit trail van de projectie.
- Als tijdstippen 'schuiven' in de herstelevents kan dat leiden tot complexe event processing.