Use CQRS When Constrained on Developers and Time

Udi Dahan wrote a funny article recently, talking about When to avoid CQRS.

So, when should you avoid CQRS? The answer is most of the time..

I deeply respect Udi's immense experience. Yet, based on my limited experience, potential surface for applying CQRS Architectural patterns and practices is much bigger, than outlined is his article.

In essence, synergies within CQRS work, whenever you need to:

tackle complexity;
distribute teams;
scale out under massive loads.

All this could happen, when you have roughly 1.2 people (that's less than one-and-a-half-developer) per project in a fast-paced development environment with limited time and resources.

Of course, this kind of "scaling" is a somewhat extreme case (although, I believe, we should be able to do even better at Lokad). Non-startup organizations don't need to fit these constraints. However wild my guess is: if CQRS approaches worked greatly for us in such situation (where N-tier, ORM, relational, DTC stuff and all their friends failed badly for scalability and complexity reasons), then they would work in less extreme situations.

CQRS Scaling

Another important thing is that the CQRS architecture and development approaches seem to work consistently under a diverse variety of conditions, such us:

Simplifying and speeding up complex entangled legacy systems.
Developing complex integration platforms reaching out dozens of unreliable systems around the globe.
Rapidly implementing simple tactical solutions with teams distributed globally.

In these very conditions classical approaches failed for us. The latter could be attributed to the fact that we (I mean "I" here) didn't have knowledge and experience required to master SOA, N-Tier, ESB and all the other things. This was complex stuff, potentially requiring years of learning, expensive courses and large teams.

Yet, for some strange reason, the mental model of CQRS provided much friendlier and faster implementation route here (despite the fact that there is not a single book published on the subject, yet). Diverse solutions being delivered to production, share similar architecture, development principles, reduced complexity levels and teams. They just work. No dedicated training courses or expensive consultants are needed for us to handle various scalability challenges, because all of them already have clear solution paths. The fact that we develop for the elastic cloud environment (which is less stable and predictable than on-premises systems), does not help to save the situation and make it less boring.

Having said all that, if you are new to the CQRS, you have two options to take:

Sign up for Udi's course on distributed systems for mere 2500 EUR.
Check out CQRS Starting point and referenced learning materials and articles.

For those who are familiar with CQRS and my work, here are some good news. I've "accidentally" decoupled core functionality of Open-Source Lokad.CQRS project from Windows Azure. After the v2 release, it should theoretically be possible to run it under Linux for embedded and cloud solutions (version .NET 3.5, if using stand-alone TPL library)

Published: April 23, 2011.

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