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.
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.