The Essence of CQRS
The acronym stands for Command and Query Responsibility Segregation, and that’s probably as far as we can go before opening Pandora’s box.
Despite the rivers of ink spilled about this pattern — or perhaps because of them — its definition and implementation details are subject to the most heated discussions; not only among practitioners but also between our tech gurus.
— I’m planning to apply CQRS to prevent unexpected behaviors.
— Good idea!
— What key-value storage would you recommend for the projections?
— You could try with… wait! What?
From the more simplistic definitions that understand it as a low-level architectural pattern to the interpretations that elevate it to the category of architectural style, full of amazing abstractions and sophisticated persistence infrastructure; there seems to be a schism between two different CQRS schools.
To illustrate the topic, we will review a few interesting personal interpretations: Greg Young as the biological father, Udi Dahan as the adoptive one, and Martin Fowler as, you know, the authority for everything related to software.
Greg Young
This guy is an authority on CQRS, basically because he himself discovered the pattern and coined its name.
In a post from 2010 entitled “CQRS, Task Based UIs, Event Sourcing agh!” he clarifies his concept with little room for misunderstanding.
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 (…).
And a few lines later.
That is it. That is the entirety of the CQRS pattern. There is nothing more to it than that… Doesn’t seem nearly as interesting when we explain it this way does it?
The entire post is devoted to clarifying what CQRS is not, provided the confusion that has surrounded it since its birth; a mandatory reading, by the way.
Special attention should be put to the following sentence — despite the questionable wording — .
This separation however enables us to do many interesting things architecturally, the largest is that it forces a break of the mental retardation that because the two use the same data they should also use the same data model.
So CQRS enables us to create separate data models, which is interesting but not mandatory at all when applying the pattern. This is worth mentioning because it is at this point where many other interpretations diverge from Young’s, assuming that this separation is the cornerstone of the pattern itself.
Let me include a last quote, this time from his personal blog, that depicts, with his characteristic sense of humor, what happened to this pattern after being shared with the world.
CQRS is not a silver bullet
CQRS is not a top level architecture
CQRS is not new
CQRS is not shiny
CQRS will not make your jump shot any better
CQRS is not intrinsically linked to DDD
CQRS is not Event Sourcing
CQRS does not require a message bus
CQRS is not a guiding principle / CQS is
CQRS is not a good wife
CQRS is learnable in 5 minutesCQRS is a small tactical pattern
CQRS can open many doors.
And yes you can support RFC 2549 using CQRS
Udi Dahan
Udi Dahan has been involved in the CQRS discovery and naming somehow, at least that is what he claims. In his article “Clarified CQRS”, he takes this humble architectural pattern and promotes it to a full-featured architecture dealing with end-to-end business processes, from the UI to the persistence layer.
CQRS is about coming up with an appropriate architecture for multi-user collaborative applications.
Dahan has been developing concepts around CQRS since the very beginning of its history, and he has held several discussions with Greg Young about different aspects of the subject. Tracking the evolution of his ideas on the topic is quite hard, since as he admits…
I think I’ve just about drove everybody crazy now with my apparent zigzagging on CQRS.
One way or another, Udi Dahan has become the main representative of the full-featured CQRS architectural style, which has become probably the most widely accepted of the two versions.
Martin Fowler
Despite referencing the aforementioned post by Greg Young, Fowler in his article “CQRS” attributes to CQRS with the splitting of the whole model into two parts, for reading and writing respectively.
The change that CQRS introduces is to split that conceptual model into separate models for update and display (…).
By separate models we most commonly mean different object models, probably running in different logical processes, perhaps on separate hardware.
That is a lot of separation, indeed. It looks like Dahan’s definition was accepted by Fowler as the source of truth.
It is worth mentioning that back in early 2010 Greg Young already replied to some of the assumptions that Fowler made in his mid-2011 post. That is what I call eventual consistency!
Take as an example Fowler’s reflections on the relationship between CQRS and CRUD.
As we move away from a single representation that we interact with via CRUD, we can easily move to a task-based UI. (…)
Like any pattern, CQRS is useful in some places, but not in others. Many systems do fit a CRUD mental model, and so should be done in that style.
And Young’s clarifications.
I would like to state once and for all that CQRS does not require a task based UI. We could apply CQRS to a CRUD based interface (though things like creating separated data models would be much harder).
The Status of the Issue
If you spend some time using your favorite search engine, you will quickly notice that the vast majority of the available content about CQRS is based on the “architectural style” approach rather than the “low-level pattern” one. Furthermore, even those that remain loyal to the original definition by Greg Young, usually refer to it along with a host of other patterns and practices. After all, the minimalist definition is not enough substance for more than a couple of paragraphs by itself; the crux of the matter is precisely the doors CQRS opens.
As we said above we have two main schools of thinking here: the minimalist one that reduces CQRS to a low-level pattern that enables the introduction of others; and the one that considers CQRS an architectural style that vertically separates state-altering operations from the side-effect-free ones, thus determining the design at every layer.
Between these two approaches, a huge variety of resources have spawned. You can find CQRS experts, consultants, and job postings; CQRS books, training, and conferences; CQRS frameworks, libraries, and cloud services. Every technical approach that involves read/write separation carries the CQRS label nowadays.
Conclusion
Did you hear the urban legend about the inventor of the sugar sticks having committed suicide because nobody opened them correctly? Every time I hear it I fear for Greg Young.
CQRS is the starter for a succulent meal, the particular dishes and recipes vary from one cook to another, but every respectable restaurant includes it in the house menu.
Personally, I am the picky one that asks for clarification every time someone mentions CQRS. For better or for worse, its current meaning is broad and open so it is advisable to clarify what are we talking about. You are free to choose which definition fits you the best, but be prepared to play spot the differences with others’ opinions when the topic comes up.
A final recommendation to deal with this diversity: do not make assumptions, there is nothing better to prevent ambiguity than a good ADR.
