What is Event Sourcing?

Events, not commands

A command requests an operation; an event records something that has happened. ShipOrder may be rejected, while OrderShipped records an accepted state transition.

An event's name and payload should express domain meaning. A generic row-updated record is not automatically a useful domain event.

A relational database can store events and audit history too. Event Sourcing describes how the application persists and derives state, not a prohibition on relational storage.

Reconstructing aggregate state

Apply an aggregate's events in stream order to reconstruct its state. This operation is often called rehydration.

A snapshot can accelerate reconstruction when it represents a known stream version. Subsequent events must still be applied, and the snapshot remains derived data.

When the model is useful

Event Sourcing can fit domains where state transitions are important and the retained event sequence supports reconstruction, investigation, or additional read models.

Evaluate the usefulness of domain events together with the cost of schema evolution, replay, and consumer operations.

When current-state storage is simpler

If an application only needs current records and straightforward queries, a state-based model may be sufficient.

Audit trails and concurrency checks are possible without Event Sourcing. Choose it for the persistence model, not because these capabilities are exclusive to it.

DDD, CQRS, and Event Sourcing

DDD defines how a domain is modeled, including aggregates and bounded contexts. Event Sourcing is a persistence approach that can be used with that model; DDD does not require it.

CQRS separates models for commands and queries. It is often combined with Event Sourcing, but the two approaches are distinct and neither requires microservices.

Practical exercise

Choose one aggregate. Describe its commands, invariants, and events, then verify that applying the events is sufficient to reconstruct the state needed for its decisions.