Event Sourcing

Event sourcing stores state as the append-only sequence of events that produced it, and rebuilds current state by replaying that log, rather than saving a snapshot and overwriting it in place.

It is not the same thing as a domain event (a fact a context publishes) or CQRS (separate read and write models). The three are distinct patterns with a one-way dependency (event sourcing leans on CQRS, not the reverse), often marketed as a bundle but held as one by no authority. All three are genuinely post-Evans: event sourcing and CQRS are absent from the 2003 book, and the domain event is only barely in it.

A caution from the person who did most to popularize it: event-sourcing an entire system is an anti-pattern. It is a local choice for the few aggregates whose history is itself valuable, not a system-wide architecture.

Signal: for a chosen aggregate, the source of truth is the event log and current state is a fold over it, while the rest of the system is not event-sourced by default. Part of Domain-Driven Design.

Sources

• Greg Young, Why Event Sourced Systems Fail: event sourcing’s chief popularizer warning against applying it to a whole system.