Wat is Event Sourcing?

Home / Blog / Achtergronden / Wat is Event Sourcing?

We kunnen Event Sourcing het beste definiëren als het ondervangen van alle veranderingen aan de staat van een applicatie genoteerd als een volgorde van gebeurtenissen. Dat klinkt wellicht ingewikkeld maar we leggen het uit aan de hand van een simpel voorbeeld.

Het is mogelijk om de staat van een applicatie op te vragen om erachter te komen wat de huidige staat is. Dat beantwoordt al veel vragen. Toch er zijn ook momenten dat we niet alleen willen zien waar we nu zijn, maar ook hoe we daar gekomen zijn. Event Sourcing zorgt ervoor dat alle wijzigingen aan de staat van de applicatie worden opgeslagen als een volgorde van gebeurtenissen. We kunnen dan niet alleen deze gebeurtenissen opvragen, maar die ook gebruiken om voorbije toestanden (states) te reconstrueren en als fundament om automatisch de state aan te passen om om te kunnen gaan met terugwerkende veranderingen.

Hoe werkt Event Sourcing?

Het basisidee van Event Sourcing is waarborgen dat elke verandering aan de status van een applicatie wordt vastgelegd in een event object en dat deze event objecten zelf weer worden opgeslagen in de chronologische volgorde waarin zij toegepast worden op de status van de applicatie.

Laten we een simpel voorbeeld nemen in het geval van track en trace informatie. In dit voorbeeld zijn er veel verschillende schepen op de open zee en we moeten erachter zien te komen waar ze zijn. Een simpele manier om dit te doen, is een tracking applicatie gebruiken met methodes die ons vertellen wanneer een schip de haven verlaat of daarin arriveert. De service wordt opgeroepen, vindt het schip en update de huidige locatie van het schip. Maar als hier Event Sourcing wordt toegepast, wordt er een stap toegevoegd aan dit proces. Nu maakt de service een event object aan om de wijzigingen vast te leggen en ze te verwerken om de status van het schip te updaten.

Voorbeeld Event Sourcing

Als we puur even kijken naar de verwerking, is dit (het gebruiken van events) een onnodige laag van indirectheid. Maar het interessante verschil is te zien bij wat er overblijft in de applicatie na enkele wijzigingen. Laten we een paar simpele veranderingen opsommen:

• Het schip ‘Willem A.’ vertrekt uit Rotterdam
• Het schip ‘Maxima’ vertrekt uit Hamburg
• Het schip ‘Willem A.’ arriveert in Antwerpen

Met de basis service (zonder het gebruik van events), zien we alleen de eindstatus vastgelegd in de ‘ship objects’. Oftewel de status van de applicatie. Met Event Sourcing leggen we ook elk event vast. We houden met Event Sourcing dus eigenlijk twee verschillende dingen bij: de state van de applicatie en een event log.

Het meest voor de hand liggende ding dat we winnen door het gebruik van Event Sourcing is dat we een logboek hebben van alle veranderingen. We zien niet alleen waar het schip is, maar ook waar het geweest is. Maar dit is nog maar een kleine winst. We zouden dit immers ook kunnen bereiken door de geschiedenis van doorgevaren havens bij te houden in het ship object of door een log file te schrijven op elk moment dat het schip beweegt. Beide opties kunnen je een goed beeld van de geschiedenis van het schip geven.

De sleutel tot Event Sourcing is dat we kunnen garanderen dat alle wijzigingen aan de domein objecten geïnitieerd zijn door de event objecten. Dit leidt tot een aantal mogelijke diensten die op het event log kunnen worden gebouwd:

• Complete Rebuild: We kunnen de status van de applicatie geheel links laten liggen en die opnieuw creëren door het opnieuw afdraaien van de events uit het event log op een lege applicatie.
• Temporal Query: We kunnen bepalen de status van de applicatie op elk gewenst moment. Fictief gezien doen we dit door te starten met een status blanco en het opnieuw afdraaien van de events tot een bepaald tijdstip of event. Je kunt hier nog verder in gaan door meerdere timelines te overwegen.
• Event Replay: Als we het idee hebben dat een voorbij event incorrect is, dan kunnen we de gevolgen uitrekenen door dat en latere events om te draaien en dan de latere events en het nieuwe event opnieuw af te draaien. (of door het weggooien van de status van de applicatie en alle events opnieuw af te draaien in de juiste event volgorde.) Dezelfde techniek kan ook omgaan met events ontvangen in de verkeerde volgorde – een bekend probleem bij systemen die communiceren via asynchrone berichtgeving.

Een goed voorbeeld van een applicatie die Event Sourcing gebruikt, is een versie controleer systeem. Zo’n systeem gebruikt redelijk vaak tijdelijke queries.