CQRS Architecture and Definitions

CQRS principle, in it's core form, merely introduces separation of reads from writes. This simple approach brings following benefits:

denormalized query persistence is optimized for the reads (which usually make up the most of the persistence IO) resulting in better performance and user experience;
we can optimize our read side for the needs of the UI (i.e.: fetching 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 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 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 - buzz-word that could mean a lot of things; also name of the "cult".
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". Documents on the CQRS Info site cover this in greater detail.

Obviously, multiple architectural designs could be established on top of CQRS Principle, DDDD is just one of them (see my CQRS Roadmap for some other possibilities). I believe, when the CQRS book finally comes out, a few designs will be covered there. Meanwhile, here are the options that I'm aware of:

DDDD - CQRS Principle + DDD + Message-based architecture + Event Sourcing
Cloud CQRS Architecture - CQRS Principle + DDD + Message-based architecture + Elastic Scaling + NoSQL persistence on top of cloud storage.
CQRS with Relational DB - CQRS Principle + Service Bus (NServiceBus/MassTransit) + ORM (NHibernate).

Each category has it's own variations and possibilities as well. For example, while evolving your legacy application towards the DDDD Architecture, you could have at some point Event Store and RDB+ORM persistence, where the latter could be dropped in some areas of the system a bit later on. In fact, enterprise system, being build with real-life approach for CQRS, would probably contain a mix of various architectures. We would be picking whatever makes the most sense for each specific business case and subsystem (basically optimizing for the highest mid/long-term business value for the development effort invested).

Better categorization of real-life CQRS architectures, their peculiarities, challenges and recommended evolution paths would probably require a bit more research. This could include gathering feedback from people practicing various CQRS flavors and structuring it on top of the theory with the formal methodologies used in universities during the PhD studies (for both learning and presenting). Maybe some time later I'll be up to this challenge.

Meanwhile, you can stay tuned to this blog and also RSS feed of CQRSInfo.com (it will get more lively a bit later).

Published: November 03, 2010.

🤗 Check out my newsletter! It is about building products with ChatGPT and LLMs: latest news, technical insights and my journey. Check out it out