Paradigm
- State of a stateful system is the result of an immutable series of changes
- Even mistakes are immutable; they are later corrected in another immutable change
- Think of an accounting ledger
- Distinguish between commands and events
- Commands can be rejected
- If a command is accepted, it leads to one or more events
- Events must always be accepted
Downsides of event sourcing
Kleppman 719:
The biggest downside of event sourcing and change data capture is that the consumers of the event log are usually asynchronous, so there is a possibility that a user may make a write to the log, then read from a log-derived view and find that their write has not yet been reflected in the read view.
Also, it can be very hard to delete data, and sometimes you have to!
Connections
Kleppman makes a strong connection between ES and change data capture.
Kleppman 712, links my own:
Event sourcing is similar to the chronicle data model, and there are also similarities between an event log and the fact table that you find in a star schema.
Who gets credit for Event Sourcing?
Kleppman ascribes Event Sourcing to the Domain Driven Design community, but I’m pretty sure it comes from (Fowler) Patterns of Enterprise Application Architecture. Evans published (Evans) Domain Driven Design in 2003, whereas PEA was published in 2002.
Claude AI tells me that DDD popularized both Event Sourcing and Command-query responsibility segregation (CQRS), which I’m certain came from PEA.