DDD/CQRS Querying Events

Question

I was looking at post's on querying in application designed with approach Event Sourcing/DDD/CQRS.

As I understand events are changes to the state of a domain object. The changes to state will be maintained as history/events in DB(any of sql/no sql).

If user wants to query to get current state for a particular aggregate root, it will involve fetching history of events.

When user will query especially business specific queries he/she will be interested in current state not the history of events.

How querying or 'Q' part in CQRS works with event sourcing?

Consider I have a domain object "Account" as aggregate root. The account AR will go through lots of changes ie credits debits. event store will have credit and debit events.

Consider user is required to get current balance of an account, how stream of history of events will suite here? How will user fetch current balance for given account?

I am unable to understand, How for business specific querying history of events will be useful?

-Prakhyat MM

Answer 1

You'll use a projection of the event stream into the read model, that contains exactly those information that the Query-side (Q) needs. For example, you could have an "account balance" projection that follows all events that change the account balance, but possibly ignores other events in the account's stream (such as owner changes). The projection then saves that info in a way that it can be queried very quickly, eg, in memory or in a small read-model database table (accountId, balance) with the accountId as the key (database can be a key-value store, for example).

I suggest further reading on the CQRS concept such as this one or this one .

Answer 2

I would recommend you to read more articles from Greg Young (He is like the father of CQRS and Event Sourcing), like this: CQRS, Task Based UIs, Event Sourcing... agh .

Sorry for my bad English, I am from Paraguay. But I really like DDD - CQRS - ES and I would like to try to make a point.

The use of "Projections" (also known as Materialized Views) and the concept of "Eventual Consistency" are the fundamentals that every practitioner of CQRS should understand very well. The Event Store is for query. Is in the Command side of CQRS, not the in the Query side. You may use a bus to send the events stored in the Event Store to the query side in order to process and generate a read model, or view models, from which you can query. In any case a eventstore per se is a query model.

Looks like you are a Java guy, but, still, you may want to check the CQRS Journey from Microsoft . Hope this helps a little bit and motivates you to do more research on DDD / CQRS / ES, the New Trio of Line of Business Applications.

Answer 3

Interesting enough, recently more people discover using event store as the read model, leaving projections and "proper" read models until absolutely necessary.

We all know that dealing with projections increases the complexity. At minimum you have to create new models, establish the DAL for the read model and create projections to translate event to the read model changes, and bind those projections to the stream of events from your store. It requires more code, more moving parts and some of them are not easy to test. Schema changes at the read side also require migrations.

It appears that for many scenarios reading all events (properly partitioned) might be enough to have your "read model". It takes not much time until the system really grows large so you need to read tens of thousands of events to create one UI screen. But before you reach this point, you can just read events. May be use the file system to store events although tools like EventStore are free and quite easy to use. May be add some indexing.

This approach let you stabilise the domain significantly, you get more knowledge about how the system works, tune the events and be really prepared to bring the "proper" read model into the system, but you might not have to.

Adam Dymitruk has wrote a blog post about it , you might find it worth reading even if you don't want to take this approach. Greg Young also gave a talk EventStore as read model back in 2012.