CQRS Pattern: An introduction to CQRS

CQRS is often confused or conflated with other patterns and architecture due to the fact that is used with those patterns and architectures. The goal of this article is to help you understand the simplicity of CQRS and to allow you to mentally isolate it and then understand how to use it so you can obtain the benefits of it.

Greg Young gave the name to the pattern and has presented many times on the topic as part of is presentations on Event Sourcing, so lets start with his definition.

CQRS Command and Query Responsibility Segregation

Starting with CQRS, CQRS is simply the creation of two objects where there was previously only one. The separation occurs based upon whether the methods are a command or a query (the same definition that is used by Meyer in Command and Query Separation, a command is any method that mutates state and a query is any method that returns a value). – Greg Young – https://web.archive.org/web/20160211235041/http://codebetter.com/gregyoung/2010/02/16/cqrs-task-based-uis-event-sourcing-agh/

CQRS is a software design pattern in which applications are split into 2 distinct parts, with each handling a single responsibility. The Command half of the code is responsible for all changes to data. The Query half of the code is responsible for querying and returning data. This article does not assume the reader is using Event Sourcing and will address how CQRS can be used with a more traditional application architecture.

This article will give you a clear and simple explanation of CQRS with images. You don’t need to write code to follow along. By the end, you should be able to visualize and explain the benefits of CQRS and how it works.

What’s in a name?

CQRS is a simple pattern with an unfortunate name. I wish Greg Young would have named it “Single Responsibility Pattern”. Perhaps it would have helped people adopt it into their projects with less hesitation. CQRS stands for “Command Query Responsibility Segregation”. So the name is telling us that it is taking two separate types of work (Commands and Queries) and breaking them apart (Segregation) into parts that handle single responsibilities. So that’s it. A strange name that means “Separate Command code from Query code”.

Single Responsibility is the Key

What are Commands and Queries?

• Commands: Do Something.

• Queries: Get Something.

Less obvious and important things you should know:

• Commands: DO NOT return values.

• Queries: DO NOT change anything in the system.

A Command will perform one action and does not return data. If it were to do an action and then run a query to return data, that would be two things, and the entire point of this is that we want it to do only one thing.

A Query will gather some data from a data store and return it. It will not perform any actions that change the system or data. It will not produce any side effects. The only responsibility of a query is to get find data and return it. Full Stop.

A view of how CQRS differs from non-CQRS

CQRS separates the code that reads from the code that changes the data it and enforces the separation of duties.

Benefits:

Simplicity: Functions and Methods now do one thing and one thing only.
Reliability: It is very easy to understand what to expect from each function or method. There are no side effects.
Scalability: It would be very easy to take the image above and go one step further and separate the Command API from the Query API so we can build, deploy, and scale them separately. It is common for sites to have many times more read traffic than write traffic so we could scale up the Query side as much as we need without scaling up all the Command resources, or vice-versa.

Rules for CQRS (using GUID ids)

Commands are void functions that change data but do not return data.
Queries select and return data but NEVER alter data.

Rules for CQRS (using database generated ids)

(same as above)
(same as above)
Insert Commands always return a database-generated Id of the object that was inserted.

Is it ok to break the rules?

It is NOT ok to break the rules of CQRS. It can be very tempting for software engineers to break the rules when it is convenient for us. Often we do this in the name of making code faster and more efficient. DON’T DO IT!

If we create a system that is CQRS, and our engineers all understand the rules, then life is simple. Everything does what is expected and that is a HUGE win. If we break the rules of CQRS just once in our project, then we have just confused everyone. Now the team (even if you are on a team of one), must always remember where the rules apply and where they don’t. The team can not rely on the rules and will be constantly surprised by side effects. If the rules exist almost all the time, but not really all the time, then the rules are 100% unreliable.

Implementing CQRS

Separate models for reading and writing:
In a traditional layered application, it is common to use the same models (DTOs, entities, etc.) for writing and reading data. Being able to re-use code is great when you need the same behavior however the intent of write-models and read-models are quite different. Because of this, we can work ourselves into a pretzel trying to use the same model for both situations. We find ourselves needing to choose between hydrating fields we don’t need, or partially hydrating a model to get just the data we need. Loading a model with unnecessary properties can cause performance problems. Using a partially hydrated model can lead to the need to write extra logic to check if fields are populated to determine behavior.

A unique and beneficial feature of CQRS is that we can and should have different models for Commands and Queries. This allows us to optimize our models for their tasks. This can make managing the logic much easier and keep the code cleaner.

Command Pattern

CQRS is commonly implemented with the Command Pattern. It is important to understand that CQRS is not the same thing as the Command Pattern. It is not required to use the Command Pattern in CQRS, but it does work well.

Separate Databases

CQRS works well when you have a read data store(s) that is separate from the write data store. It is not a requirement and CQRS can be beneficial even when there is only one data store. But when there are separate read databases, CQRS becomes a more attractive design. This is part of the reason that CQRS is particularly well suited when using Event Sourcing.

Event Sourcing

Greg Young focused on teaching CQRS to help people understand how to build effective Event Sourcing applications. ES separates the Write datastore from the Read datastore which makes CQRS almost mandatory for ES. Because of this relationship I’ve found a lot of people are confused about the distinction and separation of ES from CQRS. CQRS works well even without ES, but I would not say ES works well without CQRS.

Summary

This has been a high-level overview of CQRS that explains how the benefits of CQRS are realized by separating the code that changes data from the code that queries data. By following a few simple rules it becomes very easy for a team of developers to work together. By separating data models the code becomes more simplified and easier to work with. By separating command and query logic into separate applications it is possible and rather easy to deploy and scale each of the applications without negatively impacting the other side.

If you are going to write code to implement CQRS, you probably want to know more about how to implement it. I will be adding details on implementation either in this article or another one very soon.

I hope you have found this useful.