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.

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)

Comments

[Adam Dymitruk]

Good post. Looking forward to more RAD stuff on top of CQRS/ES.

[Stacy]

Amen! CQRS is a break-through pattern for startups.

[Rinat Abdullin]

Adam, there will be. We already plan for 3 new tactical (fast, solving specific problem) projects on top of Lokad.CQRSv2. All this experience will have to be blogged about.

[Rinat Abdullin]

Stacy, not necessarily a break-through, but probably a viable pattern for start-ups. Especially if you want to build cost-effective solutions on top of the unreliable but cheap cloud infrastructures.

[Colin Jack]

I think this post, and CQRS/ES, might benefit from some more details specifically around the reasons for using it and the tradeoffs involved along the way.

[Rinat Abdullin]

Colin Jack, I plan to have something like this published after getting experience with 5+ diverse projects on top of Cloud+CQRS architecture.

Meanwhile you can check out Lokad.CQRSv2 roadmap which includes short case studies of current projects implemented with CQRS.

[Alex]

Rinat, Udi's course is not on CQRS. I don't know if you had an opportunity to participate in his Advanced Distrubuted System Design, but it is more on SOA, EDA and system design in general than on CQRS. Sure, CQRS is touched upon, but is not a corner stone of the training. I would argue that CQRS is just a useful set of principles, while I think that SOA and EDA have much bigger impact on software architecture and design.

I also want to say that Udi's course for me was a big eye opener on a lot of ideas, subjects and approaches. Arguable it was one of the best sessions I've ever had.

[Rinat Abdullin]

Alex, I haven never been to Udi's courses. However, in the above mentioned post he says that:

If you want to know everything you need to know to apply CQRS appropriately, please come to my course

That's the reason why I've linked to it.