Command Query Separation?

There has been a lot of talk lately about Command and Query Separation. One thing that has come up with many people in learning it is that they get confused between CQS [Meyer] and CQS [Architecture or DDD]. As such many have called for us to rename the latter to something different as although it is very similar to CQS [Meyer] they find it to be quite different. I however disagree with this let’s look at our definitions.

   Separate command methods that change state from query methods that read state.

   Separate command messages that change state from query messages that read state.

The reader should notice that these two are nearly identical, the principle has remained the same, only the definitions of what commands and queries are has changed. A really quick reader will also be quick to jump on me for not bringing in all of what CQS has come to be known as.

In CQS [Architecture/DDD/whatever] we also go one step further and we create two end points (or objects) by splitting the responsibilities of the original concept. We give one sub-concept the responsibility of processing all of the commands and another the responsibility of processing all of the queries. We do this because we have come to understand that there are very different non-functional requirements for each and that by separating the two we can better tailor solutions.

One question that has been hitting me is whether or not this is something that may work as a pattern at the object granularity as opposed to the endpoint as many of these types of patterns are relevant to both scopes.

This part is new and is not CQS [Meyer] I am going to throw out a quick pattern name for this and call it Command and Query Responsibility Segregation or CQRS as we are in fact simply taking what would usually be one object and splitting its responsibilities into two objects.

So the first step is that we apply CQS as a principle, and we then come through and apply the CQRS pattern in order to end up with what people are currently calling “CQS”. I would hope that this is a clearer explanation and manages to bring in the original intent of command and query separation while realizing that there is in fact an important difference.


Does this help clear things up or does it only make things more confusing?

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

12 Responses to Command Query Separation?

  1. Pingback: OOP Best Practices: Command Query separation principle

  2. Kevin says:

    Hello Greg,

    I’ve watched your presentation in InfoQ about DDD and CQS.

    In your sample, you told that Domain Model (in CQS) is write-only. But, in this case, can I load data from database to, for example, to execute a command?

    So, is legal to load data from database when I running a command?

  3. Jurgen says:

    Dear Greg,

    I have a general question regarding the architectural separation of Query and Command DB:

    You have your commands sourced by the UI, they probably got in the command queue after some level of validation which I assume referred to the Query DB.

    When your commands are picked up by the handler… they need to go through the real validation check before they’re allowed into your sacred domain. This real validation could not be done from the Query DB, which could be a little out of sync (and which in any case may not have the same requirements of consistency). The real validation may sometimes disagree with the “UI validation”, that’s tough luck for the user. You may need to convey that message back to the UI in an intelligent manner though, which would mean that maybe some DTO’s will need to flow from your Domain model to the UI?

    But this isn’t the main question, what I’m worried about is that you seem to have to implement your validations twice, in two different bounded contexts. With possibly two different technologies underlying those two. That’s possibly a lot of duplication.

    Furthermore, you seem to like the fact that the Command DB could well be just the storage of the queue of events coming in. But how could this work with any reasonably complex validation requirements: if we want to check if the customer is still allowed to order this product this month, given the restrictions in his contract… and at the same time check if the product is still in stock in a not-too-far way site… these kind of validations could take an unreasonable amount of time to replay the events, even if you’re starting from an intermediate snapshot?

    I’m genuinely interested to understand this better. Thanks in advance for any pointers.

  4. Alexandre Garino says:

    I’d like to see an example app (package structure, etc.) which deal with the CQS pattern. Have you got some pointers?

  5. Alexandre Garino says:


    Have you any pointers of open source applications or samples following the CQS pattern. I’m interested in to know how the code, package / namespaces are organized.

  6. How about ACQS for Architectural Command Query Separation? This name embodies the intent to be similar, and the difference.

  7. CQS historically and presently means what Meyer meant it to be mean. The CQS [Young] interpretation describes a good architectural approach that shares the same underlying principles but goes further. So, similar at one level, but ultimately not the same.

    Using the same term and abbreviation is the cause of the confusion and, although the explanation is clear, anything that needs to be re-explained every time it is used (or qualified with suffixes such as [Meyer] or [Young]) is obviously suffering a usability problem.

    The naming of patterns is never necessarily an easy task (we devoted more space than anticipated to the topic in POSA5), but sometimes listening to how people might otherwise describe or explain it can provide hints as to alternative wording. The first time I had the confusion (having ignored a whole thread on the topic, because I have known for a couple of decades what CQS means… or so I thought), I realised “Oh, you mean, CQS _Messaging_. Aha!” Based on the wording you have used in the post, CQS Messaging is the explanation (also, Command-Query Separated/Segregated Messaging), the summary and a less confusing alternative handle.

  8. Daniel Auger says:

    I think CQRS describes it as an applied pattern very well, and I do like the idea of having a specific term for this pattern to avoid confusion. I’ll admit that I was completely confused a couple months ago when I first started reading about CQS [Architecture or DDD] through your blogs solely because CQS [Meyer] is typically explained with the word “method”. My mind latched on to “method” and it took me awhile to see it as a broader concept.

  9. Jason says:

    Hey Greg,

    Could I entice you into giving your thoughts and insights into when a/each context for it’s querying would go directly to the database versus through messaging into a reporting context.

  10. Illinois says:

    You got a really useful blog I have been here reading for about an hour. I am a newbee and your success is very much an inspiration for me. Please come visit my site Springfieldy when you got time.

  11. Greg says:

    I am 100% open to other names (feel free to drop them) … to me the important part is the distinction and the recognition that it is in fact the CQS principle to prevent later confusion amoungst people

  12. Jonathan says:

    Having a unique term that is search friendly is important. “Command and Query Responsibility Segregation” is a good term and would ultimately be fine, but it’s a bit of a mouthful.

    What about Command Query Distribution?

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>