Event sourcing

Wat is event sourcing?

Event sourcing is een patroon waarbij je elke verandering als event bewaart, in plaats van alleen de laatste toestand. Je slaat dus niet enkel op dat een order vandaag status verzonden heeft. Je bewaart ook dat ze eerst aangemaakt, betaald, ingepakt en verzonden werd.

De event store is de bron van waarheid. De actuele toestand bereken je door de events in volgorde toe te passen. Wil je weten hoe iets er gisteren uitzag, dan speel je de events tot gisteren af.

Het lijkt op een bankrekening. Je saldo is handig, maar de transacties vertellen waarom dat saldo zo is.

Hoe werkt event sourcing?

Elke businessactie schrijft een event naar een append-only log. Append-only betekent dat je events toevoegt, maar oude events niet zomaar overschrijft.

Een order kan bijvoorbeeld deze events hebben:

• OrderCreated. De klant plaatst de order.

• PaymentReceived. De betaling komt binnen.

• OrderPacked. Het magazijn pakt de order in.

• OrderShipped. De order vertrekt.

Voor snelle schermen bouw je meestal projecties of materialized views bovenop die events. Die projecties geven de huidige stand, terwijl de event log de volledige historiek bewaart.

Wanneer gebruik je event sourcing?

• Wanneer auditability belangrijk is. Je kan uitleggen wat er gebeurde, wanneer en door welke actie.

• Wanneer historiek businesswaarde heeft. Je wil niet alleen de huidige status, maar ook het pad ernaartoe analyseren.

• Bij eventgedreven systemen. Andere onderdelen kunnen reageren op dezelfde events.

• Voor herstel en herberekening. Nieuwe projecties kunnen opgebouwd worden uit bestaande events.

Event sourcing versus gewone CRUD

Bij CRUD bewaar je meestal de huidige toestand van een record. Een update overschrijft velden. De oude waarde is weg, tenzij je aparte auditlogica toevoegt.

Bij event sourcing schrijf je veranderingen als feiten. Je overschrijft het verleden niet. Dat geeft sterke historiek, maar ook meer ontwerpwerk. Je moet eventversies beheren, projecties onderhouden en omgaan met eventual consistency.

Waar moet je op letten bij event sourcing

• Events zijn contracten. Als andere systemen ze lezen, kan je hun vorm niet zomaar wijzigen.

• Projecties lopen soms achter. De event store is direct bijgewerkt, maar leesmodellen kunnen even later volgen.

• Replay moet idempotent zijn. Een event opnieuw verwerken mag geen dubbele neveneffecten veroorzaken.

• Niet elk domein heeft dit nodig. Voor simpele CRUD-applicaties is event sourcing vaak te zwaar.

FAQ over event sourcing

1. Is event sourcing hetzelfde als een message queue?
Nee. Een queue vervoert berichten. Event sourcing gaat over hoe je de toestand van je domein bewaart.

2. Kan ik events verwijderen?
Technisch kan dat soms, maar het breekt de auditgedachte. Voor privacy en retentie heb je een doordacht beleid nodig.

3. Is event sourcing nodig voor eventgedreven architectuur?
Nee. Je kan events publiceren zonder je volledige opslag als event store te ontwerpen.