Wat is Event Sourcing?

Bij Event Sourcing sla je niet de huidige toestand van je data op, maar de reeks gebeurtenissen (events) die tot die toestand hebben geleid. In plaats van een rij in een database die zegt "klant X heeft adres Y", bewaar je events als KlantGeregistreerd, AdresGewijzigd, AdresGewijzigd enzovoort. De huidige toestand is altijd een afgeleide: je kunt die reconstrueren door alle events opnieuw af te spelen.

Dit is een fundamenteel andere manier van denken over data. En het heeft verstrekkende gevolgen.

De voordelen die er echt toe doen

Volledige audittrail. Elke wijziging is een event met een tijdstempel. Je kunt altijd terugkijken wat er wanneer is gebeurd en in welke volgorde. Voor sectoren als financiele dienstverlening, zorg en overheid is dit geen luxe maar een vereiste.

Debugging wordt eenvoudiger. Als er een bug is, kun je de events opnieuw afspelen en precies zien waar het misgaat. Je hoeft niet meer te gissen welke reeks acties tot een foute toestand heeft geleid.

Nieuwe inzichten uit bestaande data. Stel dat je een nieuw rapport wilt maken over klantgedrag. Met een traditionele database heb je alleen de huidige staat. Met Event Sourcing kun je een nieuwe projection bouwen die de volledige geschiedenis doorloopt en precies de data oplevert die je nodig hebt.

Temporele queries. "Wat was de status van order 12345 op 3 maart om 14:00?" Met Event Sourcing is dat een triviale vraag. Met een traditionele database is het vaak onmogelijk.

Wanneer is Event Sourcing de juiste keuze?

Event Sourcing voegt complexiteit toe. Het is de juiste keuze wanneer:

  • Audit en compliance essentieel zijn. Als je moet kunnen aantonen wie wat wanneer heeft gedaan.
  • Je domein inherent event-driven is. Denk aan bestelprocessen, financiele transacties, of logistieke ketens waar de volgorde van gebeurtenissen cruciaal is.
  • Je toekomstige requirements niet kunt voorspellen. De volledige eventgeschiedenis geeft je flexibiliteit om later nieuwe views en analyses toe te voegen.
  • Je CQRS al toepast. De combinatie is natuurlijk: events voeden je read models.

De valkuilen

Event schema evolutie. Events zijn immutable, maar je domein evolueert. Wat doe je als de structuur van een event moet veranderen? Je hebt een strategie nodig voor event versioning: upcasting, weak schema's, of expliciete migratie-events.

Storage groeit. Elke actie voegt events toe. Na jaren kun je miljoenen events per aggregate hebben. Snapshots helpen: periodiek sla je de berekende toestand op zodat je niet altijd vanaf het begin hoeft af te spelen.

Eventual consistency. Je projections lopen altijd iets achter op de werkelijkheid. In de meeste gevallen praten we over milliseconden, maar je moet hier bewust mee ontwerpen.

Complexiteit van de infrastructuur. Een event store als EventStoreDB of Marten brengt operationele overhead met zich mee. Zorg dat je team de expertise heeft om dit te beheren.

Praktisch aan de slag

Begin met een afgebakend deel van je systeem. Kies een bounded context waar de voordelen het duidelijkst zijn. In het .NET-ecosysteem zijn Marten (op PostgreSQL) en EventStoreDB bewezen opties. Start met een eenvoudige projection en bouw van daaruit op.

Investeer vroeg in tooling voor het bekijken en doorzoeken van je event stream. Zonder goede tooling wordt je event store een zwarte doos.

NForza en Event Sourcing

NForza heeft ruime ervaring met het implementeren van Event Sourcing in productiesystemen. We weten uit de praktijk wanneer Event Sourcing zijn investering terugverdient en wanneer een eenvoudigere aanpak beter past. Die nuance is essentieel: de kracht van Event Sourcing zit niet in het patroon zelf, maar in de juiste toepassing ervan.