Difference between CQRS and CQS

Question

I am learning what is CQRS pattern and came to know there is also CQS pattern.

When I tried to search I found lots of diagrams and info on CQRS but didn't found much about CQS.

Key point in CQRS pattern

In CQRS there is one model to write (command model) and one model to read (query model), which are completely separate.

How is CQS different from CQRS?

Alkyd

Answer 1

CQS (Command Query Separation) and CQRS (Command Query Responsibility Segregation) are very much related. You can think of CQS as being at the class or component level, while CQRS is more at the bounded context level.

I tend to think of CQS as being at the micro level, and CQRS at the macro level.

CQS prescribes separate methods for querying from or writing to a model: the query doesn't mutate state, while the command mutates state but does not have a return value. It was devised by Bertrand Meyer as part of his pioneering work on the Eiffel programming language.

CQRS prescribes a similar approach, except it's more of a path through your system. A query request takes a separate path from a command. The query returns data without altering the underlying system; the command alters the system but does not return data.

Greg Young put together a pretty thorough write-up of what CQRS is some years back, and goes into how CQRS is an evolution of CQS. This document introduced me to CQRS some years ago, and I find it a still very useful reference document.

Dockhand

Answer 2

This is an old question but I am going to take a shot at answering it. I do not often answer questions on StackOverflow, so please forgive me if I do something outside the bounds of community in terms of linking to things, writing a long answer, etc.

There are many differences between CQRS and CQS however CQRS uses CQS inside of its definition! Let's start with defining the two and then we can discuss differences.

CQS defines two types of messages depending on their return value: no return value (void) specifies this is a Command; a return value (non-void) specifies this method is a Query.

• Commands change information
• Queries return information

Commands change state. Queries do not.

Now for CQRS, which uses the same definition as CQS for Commands and Queries. What CQRS says is that we do not want one object with Command and Query methods. Instead we want two objects: one with all the Commands and one with all the Queries.

The idea overall is very simple; it's everything after doing this where things become interesting. There are numerous talks online, of me discussing some of the attributes associated (sorry way too much to type here!).

Weepy

I think this is simply the best answer. Both CQS and CQRS are very simple concepts, yet many people complicate or confuse it. Especially when I see that CQRS = commands/queries/buses. These are great of course, but way beyond what CQRS really is. – Oliveolivegreen

I think people people confuse them because they have pretty much the same name. CQRS, CQS – Reprisal

I do not find this answer useful. What is this "one object" or "two objects"? This is not clear in my opinion. CQRS is an architectural pattern, whereas CQS is more like a design pattern. Full real CQRS would have queries totally seperated from commands (2 different projects for example). – Mill

Two objects in this response seems confusing, wouldn't "two separate models" be more readable? One data model for queries and second for commands? – Crowbar

Answer 3

• CQS is about Command and Queries. It doesn't care about the model. You have somehow separated services for reading data, and others for writing data.
• CQRS is about separate models for writes and reads. Of course, usage of write model often requires reading something to fulfill business logic, but you can only do reads on read model. Separate Databases are state of the art. But imagine single DB with separate models for read and writes modeled in ORM. It's very often good enough.

I have found that people often say they practice CQRS when they have CQS.

Andreasandree

Answer 4

Read the inventor Greg Young's answer

I think, like "Dependency Injection" the concepts are so simple and taken for granted that the fact that they have fancy names seems to drive people to think they're something more than they are, especially as CQRS is often quoted alongside Event Sourcing.

• CQS is the separation of methods that read to those that change state; don't do both in a single method. This is micro level.

• CQRS extends this concept into a higher level for machine-machine APIs, separation of the message models and processing paths.

So CQRS is a principle you apply to the code in an API or facade.

I have found CQRS to essentially be a very strong S in SOLID, pushing the separation deeply into the psyche of developers to produce more maintainable code.

I think web applications are a bad fit for CQRS since the mutation of state via representation transfer means the command and query are two sides of the same request-response. The representation is a command and the response is the query.

For example, you send an order and receive a view of all your orders.

Imagine if the code of a website was factored into a command side and query side. The route action handling code would need to fall into one of those sides, but it does both.

Imagining a stronger segregation, if the code was moved into two different compilable codebases, then the website would accept a POST of a form, but the user would have to browse to another website URL to see the impact of the action. This is obviously crazy. One workaround would be to always redirect, though this wouldn't really be RESTful since the ideal REST application is where the next representation contains hypertext to drive the next state transition and so on.

Given that a website is a REST API between human and machine (or machine and machine), this also includes REST APIs, though other types of HTTP message passing API may be a perfect fit for CQRS.

A service or facade within the bounds of the website may obviously work well with CQRS, though the action handlers would sit outside this boundary.

See CQS on Wikipedia

Mellicent

I just came across this randomly and would like to add a bit. You mention that "I think web applications are a bad fit for CQRS since the mutation of state via representation transfer means the command and query are two sides of the same request-response. The representation is a command and the response is the query." This is actually a common statement! Let me ask though, have you ever looked how say an atom feed works? How many pieces of data could be represented similar to say an atom feed? – Weepy

Hi Greg, I started writing and then I stopped and thought we'd all be better served if you answered the OP's question. I wish other authorities would cruise SO clearing matters up. I am often unsure. I often can't tell what's right from what's 5th-hand opinion or plausible sounding interpretation, I often learn the hard way. The 15 devs at my client have structured each of many APIs using a CQRS code structure which contradicts my understanding since, like a website, a POST handler on the command side also performs many queries to construct a rich return view and valid next action links. – Mellicent

There is already a link or two here linking my material on the subject which is why I didn't [had to snip] "Imagining a stronger segregation, if the code was moved into two different compilable codebases.." This is more of a REST question than say CQRS. There is nothing which says how the data is processed. A POST could be used for creating events /streams/{stream} seems a likely target (would you agree?). A GET could be going to /streams/{stream} to get the information out. There is nothing which specifies all requests for this resource must be handled by the same service etc. – Weepy

if not clear (sorry short comments) its very common as well for a POST to return a URI which the client should then issue a GET against either for latest state or for notifications (think async process) – Weepy

Thanks Greg. I agree. I did understand what you were driving at regarding posting events and consuming feeds, but thought it best if you explained in an answer where you can write more. Returning a 303 to every mutation is not typically RESTful where a state transition is more conventionally met with a response containing one or more further links or a form, so this falls under "other types of HTTP message passing API may be a perfect fit for CQRS" I think. – Mellicent

I think the idea of a webpage has matured. We are developing web clients that are work more like mobile and desktop apps that work with remote data APIs. The API server doesn't return HTML anymore. When a user PUTs or POSTs a new entity to the API server via XMLHttpRequest, the API server responses with just "201 Created". The client can do what it likes after that: request the new entity, request a list of entities, redirect to another webpage possibly for that new entity. The client and the server are more decoupled now than they were decades ago and CQRS is a good fit for Web pages now. – Janeenjanek

@TedHenry I agree. Servers responding with just HTTP codes to (mutating) requests is a common pattern, and so CQRS is suitable. However, if you're building a true REST API with hypertext controls then CQRS won't work in the program code handling the HTTP messages, much as it won't work for a browsable non-SPA website. Almost no one builds true REST APIs, driven entirely by hypertext (see github.com/lukepuplett/surfdude-csharp). – Mellicent

Answer 5

The biggest difference is CQRS uses separate data stores for commands and queries. A query store can use a different technology like a document database or just be a denormalized schema in the same database that makes querying the data easier.

The data between databases is usually copied asynchronously using something like a service bus. Therefore, data in the query store is eventually consistent (is going to be there at some point of time). Applications need to account for that. While it is possible to use the same transaction (same database or a 2-phase commit) to write in both stores, it is usually not recommended for scalability reasons.

CQS architecture reads and writes from the same data store/tables.

Weylin

For the avoidance of doubt - CQRS, when applied, allows you to use separate data stores, but that is not necessary. You can still "do CQRS", with one data store. – Nonferrous

Eventual consistency is mentioned more than once by Greg Young, but it always seems to get left out of answers on SO (that's I've seen.) – Unyoke