Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.
There are many misconceptions about CQRS. It’s often referenced alongside other patterns that can make it seem difficult and complicated. Is CQRS complicated? No. CQRS is simple. Really simple.
What is CQRS?
First, let’s tackle at the very core what CQRS actually is.
CQRS stands for Command Query Responsibility Segregation and was coined by Greg Young. CQRS is related to CQS (Command Query Separation) principle by Bertrand Myer which states:
Every method should either be a command that performs an action, or a query that returns data to the caller, but not both.
In other words, a command is a method that mutates state and query is a method that returns state. A method generally doesn’t do both, but there are exceptions to this rule.
CQRS takes CQS a step further by separating commands and queries into different objects.
To use an exampling in C#, here is a shipment class has two methods. It applies CQS, in that each method either performs an action or returns data.
CQRS Applied
If we take the above class and were to apply CQRS, we simply just need to turn this into two objects. One object would be used for mutating state (ShipmentCommand) and the other object for returning state (ShipmentQuery).
That’s it. You’ve just applied CQRS. Wasn’t that totally unexciting?
Misconceptions
I suspect the reason for the misconceptions about being complex and difficult stems from people seeing a diagram like this:
If you search google images for CQRS, you are bound to find almost every diagram that looks like the one above or some variation of it.
Is the diagram applying CQRS? Yes.
Is the diagram only applying CQRS? No.
When you hear talks or read about CQRS you are often also hearing about a bunch of other patterns or technology. Mainly those that in attempted to be represented in the diagram above.
You do not need:
- Message Broker or Bus
- Messaging
- Domain Model
- Domain Events
- Event Sourcing
- Eventual Consistency
- Separate Models for Reads and
Writes - Domain Driven Design
Enabler
I often say that CQRS is an enabler. It enables or facilitates using other patterns that often fit well together. This is why you often see CQRS and Event Sourcing applied together.
CQRS is not Event Sourcing nor does it require you to use Event Sourcing. CQRS simply fits well and enables you to apply Event Sourcing.
Fat Controller CQRS Diet
I’ve blogged a bit about how to implement CQRS without any of the other fluff. You can check out my Fat Controller CQRS Diet blog series as well as a related talk:
More
I plan on breaking down some of the misconceptions and other aspects that are often lumped in with CQRS in coming posts.
If you have any questions or comments, please let me know on twitter as I will focus my posts on those questions and comments.