Many people have been getting confused over what CQRS is. They look at CQRS as being an architecture; it is not. CQRS is a very simple pattern that enables many opportunities for architecture that may otherwise not exist. CQRS is not eventual consistency, it is not eventing, it is not messaging, it is not having separated models for reading and writing, nor is it using event sourcing. I want to take a few paragraphs to describe first exactly what CQRS is and then how it relates to other patterns.
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).
When most people talk about CQRS they are really speaking about applying the CQRS pattern to the object that represents the service boundary of the application. Consider the following pseudo-code service definition.
CustomerService
void MakeCustomerPreferred(CustomerId)
Customer GetCustomer(CustomerId)
CustomerSet GetCustomersWithName(Name)
CustomerSet GetPreferredCustomers()
void ChangeCustomerLocale(CustomerId, NewLocale)
void CreateCustomer(Customer)
void EditCustomerDetails(CustomerDetails)
Applying CQRS on this would result in two services
CustomerWriteService
void MakeCustomerPreferred(CustomerId)
void ChangeCustomerLocale(CustomerId, NewLocale)
void CreateCustomer(Customer)
void EditCustomerDetails(CustomerDetails)
CustomerReadService
Customer GetCustomer(CustomerId)
CustomerSet GetCustomersWithName(Name)
CustomerSet GetPreferredCustomers()
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? 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.
The largest possible benefit though is that it recognizes that their are different architectural properties when dealing with commands and queries … for example it allows us to host the two services differently eg: we can host the read service on 25 servers and the write service on two. The processing of commands and queries is fundamentally asymmetrical, and scaling the services symmetrically does not make a lot of sense.
Task Based UI
A task based UI is quite different from a CRUD based UI. In a task based UI you track what the user is doing and you push forward commands representing the intent of the user. 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).
There is however one thing that does really require a task based UI… That is Domain Driven Design.
The Application Service Layer in Domain Driven Design represents the tasks the system can perform. It does not just copy data to domain objects and save them… It should be dealing with behaviors on the objects… Before going further let’s look at what happened if we did; there would be no verbs in our ubiquitous language except for “Create”, “Delete”, and “Change”. While there exist many domains where this is what the Ubiquitous Language is actually like, you probably should not be using Domain Driven Design for such systems.
The concept of a task based UI is more often than not assumed to be part of CQRS, it is not, it is there so the domain can have verbs but also capturing the intent of the user is important in general. Was this a managerial override or a normal update? Does it make a difference? It depends on what question you want to ask …
Moving on to the next pattern that gets confused into CQRS
Event Sourcing
For this I want to be clear, when I use this term I am not encompassing all of what is written on the bliki. I am referring to storing current state as a series of events and rebuilding state within the system by replaying that series of events. .
On the command side of the equation, since reads are no longer on the domain, storing events can be a great way of keeping the current state. The value increases more if you decide to have two separate models (a write model and a read model) and you have a need to integrate between the two of them as you will likely be doing that through events. Since you are building the eventing anyway, why not just use the one model to manage your state?
Messaging Patterns
There is no need to use messaging patterns with CQRS. That said, if you separate your data models you will more likely than not use messaging in the integration between the models because it offers interesting possibilities.
Finally I come to the last “pattern” I hate to call it a pattern when it is really a concept that people tend to put into their definitions of CQRS and it goes hand in hand with messaging.
Eventual Consistency
Eventual consistency is also quite often introduced between the services. It is done for many architectural reasons but the largest is that it allows you to increase your scalability and availability. If you remember CAP theorem consistency if given up allows increases in the other two. Eventual consistency is extremely useful in between the models if you have them in a separated fashion but is in no way a property of CQRS itself.
Going through all of these we can see that CQRS itself is actually a fairly trivial pattern. What is interesting around CQRS is not CQRS itself but the architectural properties in the integration of the two services. In other words the interesting stuff is not really the CQRS pattern itself but in the architectural decisions that can be made around it. Don’t get me wrong there are a lot of interesting decisions that can be made around a system that has had CQRS applied … just don’t confuse all of those architectural decisions with CQRS itself.
On a personal note it feels so weird to be writing to a blog again. Writing for a book is hard, writing for a blog is easy. Pages in the book average me an hour or more while this took me just over 30 minutes to write. The less formal style allows one to write in a more stream of consciousness manner. Anyways, hope everyone enjoys the blog posts that will be pouring in over the next short period.
@ Szymon Kulec
You’re right. We need a simpler way to refer to the current most common architectures using CQRS. Not sure if this is used elsewhere but I recommend:
RIDE = Read, Intent, Domain, Events
Chosen as summary points of a typical cqrs system:
[Client] =Commands=> [Domain Model] =Events=> [Read Model] =DTOs=> [Client]
A key point is that Commands carry Intents, and summarizing a little this can be simplified:
[Client] => Intent => Domain => Events => Read => [Client]
And since a Client would typically read before having some intention, reordered:
Read => [Client] => Intent => Domain => Events
And since everything should be viewed from the Client perspective, we can leave that out:
Read => Intent => Domain => Events = RIDE
So if we’re RIDE’ing we’re going to get places faster…
Gerg, thanks for the revolution!
I’ve been using CQRS for a while now. In fact I didn’t know it was called CQRS, however the best features of it are speed,security and maintainability. Speed is obvious, however in respect of security, if I have web services then I can split off read functionality from write and apply different AD security. So I may have a read service which allows world + dog to view and a write service that only allows members of certain AD groups access. This is great when, for example, you have a web application making ajax calls to update a part of a page because only certain groups can access the write functionality. Others things are if the write service goes down, the read service may still be operational and therefore maintenance can be targeted simply and the business isn’t left twiddling its thumbs 100%. Further, version control is simplified because you know that if you update the write service and screw up at least the read service still works so you have “screw up” boundaries. Also you get nice modular deployment management which makes the network guys less nervous of change. Just a few benefits I’ve found.
Do your domain experts speak with only four verbs (Create Read Update Delete?)
I am a bit baffled by this post. I got here via Martin Fowlers CQRS post as it described something which sounded familar so I was curious. Yet I just cannot figure out what you are talking about. Lots of “it is natural that using X leads to more Q” but I have no idea as the uninitiated what the heck X is and why that leads to the holy land of more Q (whatever that is and I dont know why I need any of it).
Normally one would just ignore a blog which one finds total mystifying. You write with passion and excuse yourself with the final lines that blogging is a brain bump. And that’s cool and okay. I really am not here to troll as I have no clue what your on about. But…. (Oh dear here it comes…) the Evans book Domain Driven Design and its kinda the word of god in the architectural circles I move (CRUD like financial systems). So your statement that DDD should not be used with CRUD reads like saying “water clearly flows up hill”. Clearly it’s just a language thing that you say “antimatter” and I hear “water” so no doubt if I had any comprehension of what the heck your brain dumping about I am sure we would agree.
I suspect your domain just isn’t a natural fit to the exposed record CRUD approach. I suspect you have seen a zillion apps try to model behaviour as state then synch state models between mobile, web and backed languages as the mother of all messes when they could have just sent a verb. I suspect you are rightly freeing lesser mortals from the slavery of poor crud design in some RPC like problem spaces. And more power to you. But it really would make a better writing if you explained the problems to which you acclaim the solution. Then someone who had not drunk the coolaid would have a vague idea what problem domains work well with a (I am guessing here) a more behaviour driven design than a state driven design (???).
Pingback: Cqrs vs N-layer – Incoding framework
Pingback: CQRS: Links, News And Resources (3) « Angel ”Java” Lopez on Blog
Pingback: Kool Architectural Resources and Sample Apps(mostly in .NET) « Insight's Delight
Pingback: RESTful API ou HTTP API? | dmyoko's
Pingback: CQRS with Kevin Hurwitz and Jeffrey Palermo | Headspring
Pingback: Exploring CQRS | It works on my machine
Pingback: CQRS for MonoTouch | sgmunn
Pingback: CQRS with Kevin Hurwitz and Jeffrey Palermo | Headspring
Pingback: Design Patterns for EMR/EHR Performance | Bob on Medical Device Software
Pingback: Valtech Labs » Slipp kompromissa i din lagring
Pingback: CQRS
Pingback: CQRS – Command and Query Responsibility Segregation. – El emprendedor curioso
Pingback: Does CQRS Require a Service Bus? - Quora
Pingback: Daryl Teo's Blog » Blog Archive » Command Query Responsibility Segregation
Pingback: Why I Still Love CQRS (and Messaging and Event Sourcing)
Pingback: CQRS | Alpha's Manifesto
Pingback: CQRS | Juan Diego Raimondi
Pingback: CodeCamp 2011 – Semantic Architecture |Semantic Architecture
Pingback: Szóste Spotkanie – Command-Query Responsibility Segregation | [sckrk] Software Craftsmanship in Kraków
Sailung I am not sure I understand your first question, could you repose it or maybe bring it to the DDDCQRS google group so we can answer it more quickly?
Nice article and thank you, it is nice that domain is totally separate with other layers. what if in some case a data need to update with special condition, does it mean create new dtoReport for each condition?. So it can trigger update using single repository from Eventhandler to update record.
It seems that for each task, we need to create command, event and dto?
Sailung Limbu
@JeffG yes the read requirements on a repository quickly become a code smell
Also the structural needs in domain objects vs the behavioral needs.
Greg
Where I find these concepts useful is simply the separation of queries that are used to populate screen objects from queries that are used to populate domain objects.
Typically, most people have 1 repository layer, which always returns domain objects.
When you are populating a screen, why populate a domain object just so you can further transform that into a DTO.
Instead, the ‘screen repository’ layer is used to populate the screen DTOs. Screen DTOs have several aspects of them that do NOT belong in a domain object (such as string length validation), and don’t require populating nearly as much information as fully populating a domain aggregate.
Yes, commands / queries. This goes back as far as computer programming itself. But the fact is, when people use the repository pattern, they typically aren’t separating these 2 concepts. It helps greatly to do so.
When retrieving a domain object, there only needs to be 1 query method. That method gets the object using the PK fields that the screen DTO already knows about.
That’s the core of the separation responsibility.
@Frans if you think the storing of events is so you can “revert to any state” you completely missed the point of the event log. The whole point has to do with business value of being able to look at data in new an interesting ways by re-running the event log (see parallel models). A secondary reason is that the events are also an integration model. This cannot be done with a databases’ transaction log.
Frankly your strong opinions on something you obviously have done little research on frighten me a bit.
The concept of separation is certainly not a new idea see OLTP vs OLAP or old COM/Corba docs which recommend the same thing. Its not even new to view a system as having different paths for reading and writing. Nothing is new, Event Sourcing has been around since the 70s. Messaging is not “new”. Oddly nothing we really do in CS is “new”. I cannot however find a good reference on these materials especially not put together, surely people have done it before but I cannot find a formalized reference. If you can identify a reference I would be happy to use their vocabulary when discussing, the more interesting topics are how the pieces come together not the pieces themselves.
So CQRS is just what E. Yourdon described 2 decades ago but with a new name and new terms. Furthermore, readonly databases for retrieval of data and DML databases for data manipulation have been common for a long long time. Why is this suddenly ‘new’? What should be done, functionality wise, is as old as Software engineering itself. It’s called functional analysis. You can then group these functionality and decide what to do where and IF you implement them or not.
It gets overhead BS when you are storing the CQRS events into a db to revert to a given ‘state’. Like I said in another reply: 99.999% of the developers aren’t writing another amazon.com, and don’t need a re-implementation of a boring transaction log every RDBMS has.
IMHO, it would be great if developers first tried to learn fundamental CS principles so they already know how to create software properly instead of following the latest ‘trend’, which is currently CQRS.
Hello Greg,
one should come up with a phrase describing a set of patterns/concepts you clearly distinguished. “The Task Based UI with CQRS using Event Sourcing and Messaging Patterns” is quite mouthful, isn’t it? 😉
Greg,
Thanks for the post. CQRS has been overwhelming to learn about at times, but it helps to see the overarching, simple goal of the pattern.
I just finished watching Udi Dahan’s presentation to the London .NET User Group, and it was definitely helpful to rethink application architecture in this way. It did leave me wondering however if Udi prescribed too much for the CQRS pattern? Or do many CQRS implementations head that way anyway?
Here’s the presentation video and slide deck: http://skillsmatter.com/podcast/open-source-dot-net/udi-dahan-command-query-responsibility-segregation/rl-311
Great post! All of these ideas/patterns together sound scary if combined. But I’ve found starting with CQRS as a great way to refactor legacy applications. Gradually I add behavior to the domain / tasks in the UI and possibly then introduce some messaging if there are any legacy services involved (those usually are polling the database which is icky).
Great stuff, please do keep up with these posts.
Glad to see you’re back to blogging again! Very useful info and I agree that when applying CQRS you really need to keep KISS in mind.
Still, when you need DDD, adding CQRS and events is a great combination from many perspectives (separation of concerns, testability, operational “observability”, etc).
@Greg
Yeah, technically, I agree that CQRS is ‘nothing more’ than what you say.
But as you say here and with that previous post, once you start with the basic idea, so many architectural patterns come into play that it is easy (and IMO beneficial) to group things like CQRS and Event Sourcing together.
Plus it is so much harder to type “CQRS based architecture” every time that it is easier to just type “CQRS.”
But point well taken.
welcome back
Excellent explanation. Please keep the blog posts coming … Are you writing a book about this?
Great post. What book are you writing?