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.
Although Command Query Responsibility Segregation (CQRS) seems to be a term a lot of developers are aware of, I do think the majority have the wrong definition. Like many terms in the software development industry, things over time get confused, and then those confusing ideas propagate. These are the 3 CQRS Myths I see or hear the most often.
YouTube
Check out my YouTube channel where I post all kinds of content that accompanies my posts including this video showing everything that is in this post.
CQRS Myths
I do understand why people can be confused by CQRS as if you do a search, you’re bound to find blog posts that explain CQRS very differently. Some posts get it right, however a lot of others conflate CQRS with other concepts.
So which blog posts are right? Who has the correct definition? How do you even know what I’m writing is correct?
CQRS Definition
Greg Young, who coined the term, used to blog on CodeBetter.com and his own personal site, goodenoughsoftware.net.
Unfortunately, neither of those sites exist anymore. However thanks to archive.org, we can go back to a blog post that Greg wrote in 2010.
Example
Instead of having a single object that has both write & read operations, you would split that into two separate objects. For example:
CustomerService has methods that return state (read) and mutate state (write). In order apply CQRS, we simply need to split these up into separate objects that will do one or the other, but not both.
That’s it. CQRS applied.
So why the confusion?
I assume most of the confusion is because most examples showing CQRS are also showing a bunch of other things, which is where these myths come in.
There are so many blog posts that will show a diagram like the one above, that are applying CQRS, but also doing other things.
Myth #1: Multiple Databases
CQRS does not require you to have multiple databases. You can use the same database for writes (commands) as you can for reads (queries).
It’s not a physical separation but more of a logical one. If you’re using a relational database, you could create SQL Views that only your query side accesses.
Myth #2: Event Sourcing
Event Sourcing is the concept of storing immutable events derived from actions within your system that represent state change. Greg Young has been at the forefront of Event Sourcing, and since he coined the term CQRS, I can see how Event Sourcing often gets lumped into it.
Most often times if people are referring to both CQRS and Event Sourcing, they will use the label “CQRS/ES”. I think it’s a good idea as I hope it’s preventing more confusion.
You do not need to be Event Sourcing in order to be doing CQRS.
Myth #3: Asynchronous Messaging
You do not need to be using a message bus to apply CQRS. Commands do not need to be asynchronous. Everything can be done in a synchronous request/response manner.
I think this myth stems from people using a message bus along with Event Sourcing so they can create projects for a separate read model.
More
Greg wrote on his blog in 2012 common misconceptions that I don’t think if left us yet. Hopefully, this post shining a light on his original posts help clear things up.
