Home © Rinat Abdullin 🌟 AI Research · Newsletter · ML Labs · About

Key CQRS Ingredient

Recently there was a bit of feedback around CQRS (mostly with the regard to Lokad.CQRS for Windows Azure), where developer gets along with the architecture, design concepts and all the other exciting little things of CQRS, but then he just gets confused. There's too much tech information at once and too little ideas of where to go next.

Questions tend to be like this:

  • How do I design these commands and events?
  • Why can't I just have one command handler that processes all requests?
  • I have a problem I want to solve with Windows Azure and your framework. I did the tutorials. What do I do next?

I recall being in the same place as well: elements of CQRS architectures make sense, but aside from that it's all too overwhelming and confusing. You don't understand why is everybody so excited with all this mess. You don't see the clear learning path forward.

Let's see what we can do to simplify further learning and avoid possible disappointment.

First, we'll take a little step back and walk over the basic concepts again. We'll start with the purely technical ones (excerpt from here):

  • Command-Query Responsibility Segregation Principle is about separation of reads from writes.
  • Circular Architecture (another term that comes up in the groups; don't confuse it with the onion architecture) is about structuring these reads and writes in a decoupled way with the help of asynchronous messages (namely commands and events) and synchronous view queries.
  • Event Sourcing is another idea - persisting objects as a stream events that happened to them.

These are just technical concepts that might look cool but aren't extremely exciting on their own. These are actually the things that have been used over and over in various systems for ages with various degree of success.

Understanding these tech ideas alone is not enough for efficiently building valuable and scalable systems in the cloud and on-premises. There is the key ingredient missing from this picture: Domain-Driven Design. DDD is about understanding, explaining and evolving your domain model (that abstract thing that we are trying to express with the code) in a way that:

  • model would focus on the most important characteristics of the problem at hand (while putting less important things aside, for the sake of preserving the sanity of everybody);
  • the model could evolve and still stay in sync with reality;
  • model would help different people with various backgrounds to work together (i.e.: users, sales people and hard-core developers);
  • model would let you avoid costly development mistakes (it could even help to deliver new exciting features as a simple logical extension of what has already been implemented).

Isn't that a lot for "model": something vague that's not even a code or final architecture document of 200+ pages? Well, DDD is not just "model", but the methodology and principles to create it, distill and keep evolving afterwards. It's way of thinking, learning and talking about the business problem in a manner that implementing everything would be rather simple, despite the initial complexity of the actual problem.

CQRS architecture approaches build upon this way of thinking and created models: here we extend the DDD methodology and add new exciting ways to implement everything as a scalable and cost-effective software. We make heavy use of terms like ubiquitous language, bounded contexts, context maps, linking these directly to the technological and architectural constraints of CQRS Architectures. That's actually what Distributed Domain-Driven Design is - DDD principles enhanced with specific CQRS-based patterns-n-practices and a clear way of migrating existing systems towards better complexity management, scalability and integration capabilities.

The same is with the Cloud CQRS Architectures (or xLim 4) - Domain-Driven Design and understanding of your domain model are the important milestone to go for. Once you have it figured out - things like messages, routing, partitions and elastic scalability will just unfold on top of that model in a rather straightforward fashion without the risk of creating non-scalable, overengineered or expensive cloud computing system.

So as you can see Lokad.CQRS for Azure is not extremely important or outstanding on it's own - it is just the framework to help using DDD/CQRS principles for building systems powered by Windows Azure Cloud Computing Platform.

So if you got caught by this "CQRS hype" with all it's cool technological promises and then got stuck, I recommend to proceed as:

  • Read the Domain-Driven Design by Eric Evans.
  • Go through the materials on Cqrsinfo.com site (to cover the transition from DDD to DDDD).
  • Start a small learning project using DDD and the most familiar technologies and architectures.
  • Gradually walk through migrating this project towards the CQRS architecture (either cloud implementation or not).

These references are already available in CQRS Starting point, but I wanted to highlight the importance of DDD one more time.

Published: November 16, 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