CQRS

Learning about Command-Query Responsibility Segregation

Lucas Luna

Lucas Luna

Software Engineer
Lucas Luna

Latest posts by Lucas Luna

  • CQRS - November 4, 2019

Command-Query Responsibility Segregation, also known as CQRS, is a pattern that is quite simple to understand. If you are familiar with DDD (Domain-Driven Design) maybe you’ve heard about CQRS.

The main idea is to split the Model into two Models: one for Write and the other one for Read.

It is about dividing the Responsibility between Command and Query.

A Command is an action that changes the state of the database (create, update, delete) and a Query only returns data from the database.

Main Body

CQRS was introduced by Greg Young in 2010. He based this idea on the Command-Query Separation (CQS) by Bertrand Meyer. CQS says that every method should either be a Command that performs an action, or a Query that returns data, but not both. This allows you to increase the readability of your code base.
However, there will be situations where it makes more sense for a method that can make an action and return data. A create could save the item and return the Id.

Benefits

  • Scalability

If you are building or you have built an application, you may notice that among all operations to the database usually the most used is READ and It is important to be able to scale the READ Model.

You could host the Command Model on a single server and you could create a cluster of multiple serve for the Query Model. 

  • Performance

Even if you decide to host Commands and Query on the same server you could split the API into two and you can still apply optimization techniques that wouldn’t be possible with a single unified Model.

Just having a separate set of APIs for Queries allows you to set up a cache for that specific part of the application.

It also allows you to use highly sophisticated SQL queries for reading data from the database without looking back at the command side of the application.

Where in the Domain Model we probably use an ORM like Entity Framework or Hibernate, the Command side and the Query side have different needs and a different Model.

  • Simplicity

You can focus on each of them and introduce a separate solution that makes the most sense in each particular case.

You can view this as the Single Responsibility Principle (From SOLID concept) applied at the architectural level.

Conclusion 

In the end, you get two models, each of them does only one thing, and  in the right way.

We split the responsibility into Command and Query, and we could use an ORM (Entity Framework or Hibernate) for the Command side and highly optimized SQL queries (ADO .NET).

To improve the benefits, we can use in Command side to store data in a relational database, then synchronize the data into a NoSQL database to be consumed from the Read side.

……………………………………………………………………………………………………………………………………………………………………………………….

About this presentation

On September 2019, Cognizant Softvision celebrated the 5th edition of Programmers’ Week, a global event where more than 140 speakers delivered technical-talks from Argentina, US, Canada, India, Ukraine and Romania. Lucas Luna, who is based in Buenos Aires, delivered a presentation about CQRS at the event.

Share This Article


Lucas Luna

Lucas Luna

Software Engineer
Lucas Luna

Latest posts by Lucas Luna

  • CQRS - November 4, 2019
No Comments

Post A Comment