I ett blogginlägg, som helt enkelt heter Event Sourcing, förklarar Martin Fowler att Event Sourcing (ES) innebär att varje enskild tillståndsförändring i ett system representeras av en händelse som sparas tillsammans med alla andra händelser, i en kronologisk log. Fowler lyfter några fördelar med detta:

1. Complete Rebuild - hela systemets nuvarande tillstånds kan återskapas genom spela upp alla händelser på nytt.
2. Temporal Query - vi kan avgöra systemets tillstånd vid en given tidpunkt (från systemets start fram till nu).
3. Event Replay - vi kan lista ut effekten av en given händelse genom att skapa upp det nuvarande tillståndet på nytt, utan den aktuella händelsen (t ex om händelsen på något vis är felaktig).

Fördelar

ES är en förlängning av Domain Driven Design (DDD), och en av frontfigurerna inom ES är Greg Young. I ett föredrag från Code on the Beach 2014 (YouTube) har Young några exempel på fördelar som ES för med sig:

1. Händelseloggen är automatiskt även en “audit log”.
2. Datastrukturerna för att repesentera ett systems tillstånd har en benägenhet att förändra sig oftare än systemets beteenden. ES gör att vi slipper datamigreringar, eftersom vi kan skapa om det aktuella tillståndet genom att spela upp alla händelser från början (“Complete Rebuild”).
3. Affärssidan av verksamheten uppskattar ES, eftersom data aldrig förstörs utan bara läggs till i händelseloggen. Det möjliggörs t ex rapportgenerering för tidpunkter bakåt i tiden (“Temporal Query”).
4. Många domäner tillämpar redan ES, t ex bokföring.
5. Många “mogna” verksamheter så som bank, försäkring och börshandel tillämpar redan ES.
6. I sammanhang där inte systemet representerar det faktiska tillståndet, t ex ett lager, passar ES naturligt in.

Nackdelar

Greg Young resonerar även kring förekommande oro att ES medför eskalerande kostnader för lagring, eftersom att varje händelse måste lagras istället för bara det nuvarande tillståndet. Två reflektioner han gör är:

1. Produceras data i långsammare takt än Moores lag föreskriver, så kommer kostnaden för lagring bara minska över tid.
2. Undvik helst snaphots (aggregerade händelser), eftersom det medför komplexitet. Upp till 1000 händelser för ett aggregat bör inte meföra prestandaproblem.

Fördjupning

På Domain-Driven Design Europe 2016 (YouTube) så utvecklar Young några av sina tankar kring ES:

1. ES är inte ett arkitekturellt mönster, utan något som appliceras ovanpå t ex en händelsedriven arkitektur.
2. ES är inte någon generell lösning, utan något som bör tillämpas där det finns behov.
3. ES är en funktionell modell som kan realiseras med koncepten: mönstermatchning, fold och funktioner.
4. Det finns inga “one-way commands” (“fire and forget”) inom ES, eftersom den som skickar ett kommando bör vara beredd på att kommandot kan avvisas. En händelse är någonting som har inträffat och inte kan förändras, medan ett kommando kan avvisas efter t ex validering.