Listening to DDD / CQRS Events

Question

I watched the request message in an application developed with the Event Sourcing / DDD / CQRS approach.

As I understand it, events are changes in the state of a domain object. Changes in state will be supported as history / events in the database (any of sql / no sql).

If the user wants to query to get the current state for a specific aggregate root, it will include retrieving the event history.

When a user requests special requests for a particular business, he / she will be interested in the current state, not the history of events.

How does a query or Q part in CQRS work with an event source?

I have an Account domain object as a cumulative root. The AR account will go through a lot of changes, i.e. debits loans. The event store will have credit and debit events.

Consider that the user should get the current account balance, how will the event history stream be located? How will the user receive the current balance for this account?

I can’t understand how useful a business event history query is?

-Have M M

Answer 1

You will use the projection of the event flow into the reading model, which contains exactly the information that the request side (Q) needs. For example, you might have a “account balance” forecast that follows all events that change the account balance, but possibly ignore other events in the account stream (for example, owner changes). The projection then stores this information in such a way that it can be requested very quickly, for example, in memory or in a small read-model database table (accountId, balance) with the key accountId as the key (the database can be a repository of key values, for example) .

I suggest that you continue reading the CQRS concept, such as this or this .

Answer 2

I would recommend you read more articles from Greg Young (he looks like the father of CQRS and Event Sourcing), for example: CQRS, task-based user interface, Event Sourcing ... agh .

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

The use of “Forecasts” (also called materialized species) and the concept of “Final Consistency” are the foundations that every CQRS practitioner needs to understand very well. The event store is for the request. The command line is CQRS, not the query side. You can use the bus to send events stored in the event store to the request side, to process and generate a reading model, or to view models from which you can request. In any case, the eventstore itself is a request model.

It sounds like you are a Java guy, but nonetheless, you can check out CQRS Journey from Microsoft . Hope this helps a little and encourages you to do more research on DDD / CQRS / ES, the new trio of linear business applications.

Answer 3

Interestingly, more and more people have recently discovered the use of the event store as a reading model, leaving predictions and “correct” reading models until they are absolutely necessary.

We all know that working with projections increases complexity. At a minimum, you need to create new models, set the DAL for the reading model, and create forecasts for translating events into modified model models and associate these forecasts with the flow of events from your store. This requires more code, more moving parts, and some of them are not easy to verify. Read-side schema changes also require migration.

It seems that for many scenarios, reading all events (properly partitioned) might be enough to have your “read model”. It will take a long time until the system really grows, so you need to read tens of thousands of events to create a single user interface screen. But before you reach this point, you can just read the events. A file system can be used to store events, although tools like EventStore are free and fairly easy to use. Some indexing may be added.

This approach will allow you to significantly stabilize the domain, you will gain more knowledge about how the system works, configure events and be prepared to prepare for the “correct” model of reading into the system, but you may not need it.

Adam Dymitruk wrote a blog post about this , you might think that it is worth reading, even if you do not want to use this approach, Greg Young also gave the word EventStore as a read model in 2012.