Rinat Abdullin

Here's PDF that maps my top 10 reasons to use Command-Query Responsibility Segregation in your development. These reasons are about benefits of CQRS and things that it enables to do: Domain-Driven Design, Event Sourcing, Cloud Computing etc.

This map is made in a form of research/skill tree (just like the one in Master of Orion 2 or Diablo 2) and shows my take on the dependencies between these different architectural elements along with the benefits they provide. In essence these are potential paths of evolution that your system might go through as it matures and faces new scalability, complexity or business challenges.

Download PDF | Download Hi-Res PNG | Permalink

This CQRS roadmap was inspired by the question of Samuel Jack on CQRS applicability in small systems that don't require massive scalability. There were a few other similar questions as well. Apparently, by pushing CQRS to the theory of almost-infinitely scalable systems, I've made an impression that scalability is all that is out there.

I think, large scalability is not the only reason to try CQRS architectures (and any of the other features down the "research tree"). However if you discover that you need to reduce complexity, bring up the scalability or add smarter business intelligence - these paths will still be open for you in a rather straightforward way.

In fact, another inspiration for the outline was the current process of jump-starting yet another Lokad project on top of Lokad.CQRS for Windows Azure. This project is bound to be simple, robust and flexible enough to handle new business requirements as they come - a perfect fit for CQRS.

You are welcome to download this CQRS "research tree", share it, print out as a reference (it should scale to 2 A4 sheets by default), use to persuade your boss or colleagues about some long-term refactoring investment or do pretty much what you like.

Do you like it?

PS: this post is a proud member of xLim 4: CQRS in Cloud series, but it's applicability is not limited by the cloud.

I would add defensive coding, from the view that if your aggregate roots (or whatever objects form the boundary into your domain) are used only on the command side and therefore can be constructed without any setters, getters or methods which return an object which could then be modified from outside the class, you remove what I would say is the easiest way for users of your domain objects to put them into an invalid state.

Erin, thank you for bringing this up. I'll need to update the map, once there is enough feedback.

Rinat,
Thanks for that - it's a very helpful diagram.

Over the last year or so I've been seeing more and more the benefits of a message orientated system in reduced complexity (in fact, I'm just in the process of migrating our current application from a traditional WCF service/method style architecture to a message based architecture). I can see a rather natural progression from there to CQRS. The part I still need to grasp is the jump from CQRS to Event Sourcing - and whether that would be useful in our case. I guess I'll have to go back and read some of your previous articles!

Anyway, keep up the good work. I don't care if your articles do give me Architecture Envy - they're always very interesting!

To complexity management I would add Bounded Contexts and Context Map (this overlaps a little with Construction Bonus).

Samuel, thank you)))

As for the transition from CQRS to Event Sourcing: I think it makes real sense when you are comfortable with the DDD and have it in your architecture. That's how it was initially with me - the whole concept didn't make sense, although I was really trying to reason the benefits and follow Greg's ideas. Then I was forced to start using DDD practices and approaches to manage complexity and let system still evolve. It worked. Then ES suddenly "clicked" as well. With DDD in place (even partially) Event Sourcing starts making perfect sense and becomes a natural evolution step for larger projects.

All the best.

Yves,

Thank you for the suggestion, I'll have it in the next version of "CQRS Roadmap"

I'm with you up to Digital Nervous System. I don't know about Eric Meyjer, but Bill Gates did not arrive there via CQRS. Do you remember Windows DNA?

Michael,
Yes, of course, there are multiple ways to arrive at the technology. Personally for me DNS is easily achievable via the messaging and CQRS architectures (with the clear benefit that there are tons of information on building, scaling and managing such projects). Gates and Meyjer just happened to be talking about things that help to arrive there.

Re DNA - not clearly. It was discarded in favor of .NET, which was initially created "to build web services" and then started getting ahead of itself. That's when I got aboard.

Best regards.

Very nicely presented.

One question, what about standard queries/ requests such as GetProducts() which expect results back? Do you regard this kind of a request as a command (it doesn't change the data) and suggest to use messaging to get back results or use web services in a standard way?

Thanks in advance.

Hantana,

Queries against the read side are made in a sync mode without the messaging (since they are optimized for the reads). There is no need to use messaging for that in the CQRS model; it is usually reserved for commands that change state.

Does this help?

Yes.

So one way of implementing queries against read side is to use asynchronous web services. Am I right?

Have you experienced better performance when you optimize reading side of database for searching and reporting (by following Command - Event - Query model)? In a standard application these two operations take longtime to complete.

Thanks.

For the read side - not asynchronous, but synchronous.

Yes, better performance is one of the benefits, along with added flexibility and *much* simpler read queries. Plus, this also improves the performance on the write side and auto-handles deadlocks (since we no longer stress the write side for the reads, which usually cause the most stress to the persistence)

Thanks Rinat. This is definitely helpful.