Loading content
Event Sourcing is an architectural approach that allows tracking the state of a system by storing events. Instead of directly storing the current state, all changes are recorded as events. This enables a complete history of changes and facilitates restoring states at a specific point in time.
Use this profile to understand the building block briefly, place it in the model, and switch to the 360° assessment when needed.
Theoretical construct: explains a term, principle, or mental model.
What organizes, connects, or makes decisions possible.
Event Sourcing stores domain changes as immutable events and derives the current state from them.
The approach was described in the mid-2000s by Martin Fowler in the context of Enterprise Application Architecture. It emerged from a familiar CRUD problem: systems usually keep only the latest state, lose history, make earlier states hard to reconstruct, and run into contention when multiple writes compete. Event Sourcing answers with an append-only sequence of events as the authoritative source.
Think of a durable event log for each domain object. Every action appends a new event; the current state exists only after the stream is replayed in order. For querying, the system builds projections or materialized views from that log. When streams get long, snapshots help; when rules or data shapes change, schema versioning and sometimes compensating events are needed.
The chronological sequence of all domain changes for an object or aggregate.
State is reconstructed from stored events instead of being read directly.
A derived view of events optimized for fast and simple queries.
New events are appended only if the read state is still valid and no intervening change has occurred.
Events and readers must cope with evolving data shapes and fields.
Multiple local steps are coordinated into one broader process through events and compensations.
Events are shaped by domain language, bounded contexts, and domain rules.
Event Sourcing is useful when auditability, historical reconstruction, debugging, or domain traceability matter more than simple point-in-time reads. It often fits complex domains and systems with multiple read models. The trade-off is higher effort for modeling, projections, concurrency control, and migration; for many standard applications, classic CRUD is enough.
Where this building block is located in the topic model.
No structure path available.
Explore how this building block connects to concepts, methods, technologies, and tools.
These sources establish the term and its professional meaning.
All direct connections of the current building block in a compact text view.
This classification shows where the building block typically matters, how demanding it is, and what kind of impact it has in the model.
The level within the organization (enterprise, domain, team) at which the AssetBlock is applied.