Even though the name itself states the intentions clearly – Command and Query Responsibility Segregation A.K.A CQRS, with my never ending habit of questioning everything, I just could not stop myself from digging deeper into this buzz word.
So here is what I have summarized about CQRS that might be helpful to anyone who is interested in learning and implementing it.
Lets understand what CQRS is ? What is its basic principle ? How one can benefit from it ?
A Little History for those who care ....
How it came to be ? Who coined the term?
The design principle – Command Query Separation was coined and introduced by Bertrand Meyer in his groundbreaking book published in 1988 – Object-Oriented Software Construction. This book is often considered a foundational text of object-oriented programming, being cited thousands of times in various languages.
His work on this book even won him the Jolt Award in 1994.
CQRS was later on introduced by Greg Young which is based on this same principle – command query separation.
CQRS Basic Principle
What does it say ?
First of all, It is a software design pattern for cloud distributed systems. If you wish to know where it lies in the overall categories of patterns – take a quick peak into this diagram.
According to Meyer, There are two types of methods in an object-oriented software –
- commands – performs some kind of action (insertions and updates )
- queries – returns some kind of data to the caller (reads)
So in layman’s terms – It simply states that a method should not do both – commands and queries at the same time.
A method should either Change the State of an Object (the COMMAND),
or Return a Result (the QUERY), but Not Both (the SEPARATION)– Bertrand Meyer
Your commands (inserts, updates, deletes) eventually changes the state of your system while returning no data. Hence they will have side effects (mutates states) within the application.
Queries on the other hand have no side effects because all they do is give back some data and they do not change the application state what-so-ever.
What CQRS is not ?
Avoid the mis-conceptions
CQRS is simply a concept which talks about creating two different objects for reads and writes where previously the same thing used to be done by a single object.
The separation occurs based upon whether the method is a command or a query.
- It is not eventing
- It is not messaging
- It is not using event sourcing
It is just a simple concept or pattern that talks about separating roles.
Implementing CQRS
How one can benefit from it ?
Lets take a look at a real world example of a learning management system. Here we have a set of services that a typical LMS can offer:
Well that is all what CQRS is about in the simplest. So what is so good about this approach ?
Well, in most of the real world applications, your users will be doing more reads than writes into the system. Implementing CQRS in such cases will empower you with the ability to host your two services separately ( may be host 15 services to perform reads and only 2-3 services to perform writes – a.k.a horizontal scalability).
Here are some key benefits :
- Separation of concern
- Dedicated/ individual deployment of commands and queries
- Scalability
- Testability
Any drawbacks ?
The first thing to note when implementing CQRS is –
you will be doing a strict split between things that performs read operations and things that perform write operations. So, eventually you will be creating two separate objects for them (dedicated components).
So, when you are dealing with a rather complex system and you do not implement CQRS only where it is needed – you will be introducing unwanted complexities in the system.
Common Usage
How do people apply CQRS ?
CQRS can be implemented in many ways. One can implement it with or without other patterns and architectures and still grab the benefits. To name some :
- Basic CQRS ( one database shared by both command and query models)
- Two databases ( one for command and the other for query)
- In an event-driven architecture
- Alongside Event Sourcing pattern
- With a Materialized View pattern
