Understanding CQRS

This is the internal structure of CQRS. There is no specific framework to follow. Systems aren’t always fully CQRS compliant and have modifications according to their needs. I am going to use infographics to give a more detailed view and easy understanding. You don’t have to follow this system; it’s just to understand the idea.



Details

The idea of separating the read write models is applied for leaving you with an option of scalability and flexibility. But, most systems use the same model for the view, that they use for the read and write model. This is not a good way to use it because you should only provide the information in the view that is required, no need to provide extra information. Also, it’s a better way of performing the domain encapsulation, so that your domain objects are not visible to the outside world. As seen, an action or set of actions could generate a number of events which are stored in event stores.

Based on those, the event aggregators are used to aggregate the events for figuring out the final behavior. In our case, the aggregate is a balance but in some systems, where transaction is not the case, these aggregates could give the latest information. For instance, we have a system where a view should show what the team is working on at mid-day, for each team member in a team. If a team member is changing his/her activities too often within a short span of time, maybe that information is not important. So, we aggregated those events from which we can extract the latest information. These types of scenarios are mostly based on the nature of the systems.

In the infographics, I tried to explain the infrastructure involved in a complex system. Off course, that is not a real system which probably would be much more complex and a lot different than this system. In banking sectors, we always calculate the remaining balance as an aggregate of transactions. Use the same thinking when it comes to any other system dealing with events. So, when we see the aggregate of the event, we see the final state of the system. We can’t remove any event, else we will lose its state.

Understand Event 

,

You can see here, if we delete one event, we will have a different result.

The other part of the system is those multiple DBs or tables dedicated for those systems. That is kind of similar in CQRS too. In CQRS, it’s better to have one table for a view. So, in our simple example, if we have an  ATM, we don’t need to save all the transaction history and personal detail of account to the DB, but all we want is just the identification and balance history. From that, we can show and conclude different operations.