In this blog, we will discuss CQRS and how it is different from old approaches.
CQRS stands for Command Query Responsibility Segregation.
The approach that individuals use for interacting with a data system is to treat it as a CRUD datastore. By this, I mean that we have a mental model of some record structure. We think about producing new records,
One cannot really enjoy the advantages of CQRS without considering the user-interface. Creating it captures the user purpose expressly, taking into consideration client-side validation and command structures could also be somewhat balanced.
Tradition Approach
As this happens we start to visualize multiple representations of knowledge. Once users move with the data they use various displays of this information, every of that may be a totally different representation. Developers generally build their own abstract models that they use to control the core components of the model. If you are employing a Domain Model, then this can be typically the complex illustration of the domain. You usually also create persistent storage as on the point of the abstract model.
Problem with the CRUD approach:
This structure of multiple layers of representation will get quite complicated, however, what one can do is that they still resolve it right down to one conceptual representation that acts as a conceptual integration point between all the displays
As our needs become more advanced we have a tendency to steadily move away from that model. We have a tendency to look at the knowledge in a very completely different way than the way we the record, maybe collapsing multiple records into one or forming virtual records by combining info. On the update, we have a tendency to notice validation rules that enable combinations of knowledge to be held on, or might even infer knowledge to be held on that is completely different from that we have provide.
CQRS Approach
By separating models we most commonly mean totally different object models, most likely running in several logical processes, maybe on separate hardware. An online example would be to see a user viewing an internet page that is executed using the query model. If they initiate a change then the modification is routed to the separate command model for the processing, the resulting change is communicated to the query model to render the updated state.
Benefits of CQRS
- CQRS permits you to separate the load from reads and writes, permitting you to scale each independently. If your application sees a gain inequality between reads and writes this is often very handy. Even without that, you’ll apply totally different improvement methods to the two sides.
- Using CQRS on a domain that does not match it’ll add complexity, therefore reducing productivity and increasing risk.
Write-side vs. Read-side in CQRS
A benefit of this pattern is the separation of concerns between the write and the read-side. Then the entities can focus on updating commands and the read-side can be optimized for various queries and reporting jobs. A single conceptual model that tries to encapsulate both read and write operations may do neither well.
It is important to realize that the write-side has completely different needs from the read-side, and separating those concerns makes it possible to offer the best experience for the write and read-sides independently.
This separation is also great for scalability since the read-side can be scaled out to many nodes independently of the write-side, and its often on the read-side that you need massive scalability.
A consequence of separating the read-side is that it is eventually consistent, i.e. it may take a few seconds until an update to the write-side is visible on the read-side.
Caution with CQRS :
Not a silver bullet, every case doesn’t fit with this CQRS approach.
Many systems do fit a CRUD mental model, and they should be wiped out of that style. CQRS may be an important mental leap for all concerned, therefore should not be tackled unless the profit is definitely worth the jump.CQRS should only be used on specific portions of a system and not the system as a whole.
Lagom is an open-source microservice framework built on top of the Akka and Play frameworks. Lagom Persistence makes use of Event Sourcing and CQRS to help achieve decoupled architecture.
You can find real-life examples of how Lagom handles Event Sourcing and CQRS in the following blogs:
References
