One simple trick to make Event Sourcing click
By: Paweł Pacana
Tags: Event Sourcing, Ruby, Ddd

Event Sourcing is like having two methods when previously there was one. There — I’ve said it.

But it isn’t my idea at all.

It was Greg that used it first, in a bit different context. When explaining CQRS he used this exact words:

Starting with CQRS, CQRS is simply the creation of two objects where there was previously only one. The separation occurs based upon whether the methods are a command or a query (the same definition that is used by Meyer in Command and Query Separation, a command is any method that mutates state and a query is any method that returns a value).

You can have quite a similar statement on event-sourced aggregate root. The separation occurs based upon whether the method:

corresponds to an action we want to take on an aggregate — protects business rules and tells what domain event happened if those were met

we want to take on an aggregate — protects and tells what domain event happened if those were met maps consequences of the domain event that happened to internal state representation (against which business rules are executed)

Not convinced yet? Let the examples speak.

Stereotypical aggregate without Event Sourcing

Below is a typical aggregate root. In the scope of the example there are only two actions you can take — via public register and supply methods.

Aggregate with Event Sourcing

In event sourcing it is the domain events that are our source of truth. They state what happened. What we need to do is to make them a bit more useful and convenient for decision making. This is the sourcing part.

In this step we’ve drawn the line between making a statement that something happened (being possible to happen first) and what side effects does it have. Notice private registered and supplied methods.

Why make such effort and introduce indirection? The reason is simple — if the events are source of truth, we could not only shape internal state for current actions we take but also for the ones that happened in the past.

Instead of loading current state stored in a database, we can take collection of events that happened in scope of this aggregate — in its stream.

At this point you may have figured out that event_store dependency that we constantly pass as an argument belongs more to the infrastructure layer than to a domain and business.

What if something above passed a list of events first so we could rebuild the state? After an aggregate action happened we could provide a list of domain events to be published ( unpublished_events ):

More or less this reminds the aggregate_root gem that is aimed to assist you with event sourced aggregates.

The rule of having two methods when there was previously one however still holds.

The public method (such as supply ) corresponds to an action we want to take on an aggregate — protects business rules and tells what domain event happened if those rules were met.

(such as ) corresponds to an we want to take on an aggregate — protects and tells what domain event happened if those rules were met. The private method (such as supplied ) maps consequences of the domain event that happened to the internal state representation.

There are more code samples and The Why of Event Sourcing in Rails Meets DDD which I fully recommend.

Have a great day!