The Event Sourcing pattern adopts a different
approach in storing application state,
retrieving application state, and publishing
application state changes within the various
Bounded Contexts of an application.
Before we get into the details of event sourcing,
let us look at the traditional approach
of state maintenance.
Traditional applications use “Domain Sourcing
or State Sourcing” to store/retrieve
Aggregate state. The concept of domain sourcing
is that we construct, modify, or query
Aggregate state using a traditional data storage
mechanism (e.g., Relational Databases, NoSQL
Database). Only once the Aggregate state has
been persisted do we publish the event onto a
message broker. Our previous implementations
have all been based on “Domain Sourcing.”
Domain-sourced applications are fairly
straightforward in usage since they use the
traditional mechanisms of storing and retrieving
state. The state of an Aggregate within the
various Bounded Contexts is stored as is
whenever there is an operation on the
Aggregate,
, for example, when we Book a New Cargo, a new
cargo is created, and the details of the new
cargo are stored in the corresponding CARGO
table in the database (in our case a Database
Schema within the Booking Bounded Context).
We raise a New Cargo Booked Event which
is pushed onto a traditional message broker
which can be subscribed by any other bounded
context. We use a dedicated message broker onto
which these events are published.
On the other hand, Event Sourcing works
exclusively with events that occur on
Aggregates. Every change of state of an
Aggregate is captured as an event, and only the
event
is persisted instead of the whole Aggregate
Instance with payload as the Aggregate Instance.
Again to reemphasize, we only store the event
and not the
aggregate as a whole.
As depicted, at the end of the “Book New Cargo”
operation, we persist only the
“Cargo Booked Event” and not the Cargo
Aggregate Instance. The event is persisted in
a specialized purpose-built Event Store. The
event store in addition to acting as the
persistence store for events also needs to double
up as an Event Router, that is, it should
approach in storing application state,
retrieving application state, and publishing
application state changes within the various
Bounded Contexts of an application.
Before we get into the details of event sourcing,
let us look at the traditional approach
of state maintenance.
Traditional applications use “Domain Sourcing
or State Sourcing” to store/retrieve
Aggregate state. The concept of domain sourcing
is that we construct, modify, or query
Aggregate state using a traditional data storage
mechanism (e.g., Relational Databases, NoSQL
Database). Only once the Aggregate state has
been persisted do we publish the event onto a
message broker. Our previous implementations
have all been based on “Domain Sourcing.”
Domain-sourced applications are fairly
straightforward in usage since they use the
traditional mechanisms of storing and retrieving
state. The state of an Aggregate within the
various Bounded Contexts is stored as is
whenever there is an operation on the
Aggregate,
, for example, when we Book a New Cargo, a new
cargo is created, and the details of the new
cargo are stored in the corresponding CARGO
table in the database (in our case a Database
Schema within the Booking Bounded Context).
We raise a New Cargo Booked Event which
is pushed onto a traditional message broker
which can be subscribed by any other bounded
context. We use a dedicated message broker onto
which these events are published.
On the other hand, Event Sourcing works
exclusively with events that occur on
Aggregates. Every change of state of an
Aggregate is captured as an event, and only the
event
is persisted instead of the whole Aggregate
Instance with payload as the Aggregate Instance.
Again to reemphasize, we only store the event
and not the
aggregate as a whole.
As depicted, at the end of the “Book New Cargo”
operation, we persist only the
“Cargo Booked Event” and not the Cargo
Aggregate Instance. The event is persisted in
a specialized purpose-built Event Store. The
event store in addition to acting as the
persistence store for events also needs to double
up as an Event Router, that is, it should
