Command-Query Responsibility Segregation (CQRS) is an architectural pattern which separates commands (that change the data) from queries (that read the data). See 'about cqrs tag' for more details and references to learning materials. Not to be confused with Command-Query Segregation ([CQS]), a principle of object method design which CQRS incorporates.
The Command-Query Responsibility Segregation (CQRS) principle, in its core form, merely introduces separation of reads from writes. This simple approach brings the following benefits:
- denormalized query persistence is optimized for the reads (which usually make up the most of the persistence I/O) resulting in better performance and user experience;
- we can optimize our read side for the needs of the UI (for example, fetching the dashboard for the user in a single query) which will result in better development experience and less risk of breaking something on the write side.
- read side can be put on some cloud storage, which is inherently optimized for the reads, could be partitioned, replicated and even distributed via a CDN;
- by offloading data reads to synchronous queries we automatically increase the performance of the write side - now it has lower stress and lower probability of hitting a deadlock (which you should still account for).
Deeper introduction and more learning materials are available for study in CQRS Starting Point.
What about things that you hear in any CQRS talk: commands, events, DDD, eventual consistency and almost-infinite scalability? These are distinct architectural patterns with their own benefits and peculiarities. These patterns play so nicely with the CQRS principle (separation of reads from the writes), that they are often perceived as one thing.
So when we say "CQRS" this often means: "CQRS Principle" + "Message-driven architecture with commands, events and queries" + "Domain-Driven Design Methodology". This combination is one of the most frequent variations of "CQRS Architecture" (sometimes Event Sourcing is included there by default as well). Success of this variation is the reason why there is so much buzz and hype around the original CQRS term.
So here's what we have here:
- CQRS - buzzword that could mean a lot of things.
- CQRS Principle - principle that dictates separation of reads from writes in your system.
- CQRS Architectures - specific architectural designs based upon the CQRS Principle and a few other time-proven methodologies and approaches. They usually come with a clear evolution path enabling migration of live application to more elaborate design, if needed.
- DDDD (Distributed Domain-Driven Design) - one of the CQRS Architectures, as presented by Greg Young. It is based upon "CQRS Principle" + "DDD" + "Message-based architecture" + "Event Sourcing".
Not to be confused with Command-Query Segregation (cqs), a principle of object method design which CQRS incorporates.
