When to use the CQRS design pattern


My team and I have been discussing using the CQRS (Command Query Responsibility Segregation) design pattern and we are still trying to asses the pros and cons of using it. According to: http://martinfowler.com/bliki/CQRS.html

we haven't seen enough uses of CQRS in the field yet to be confident
that we understand its pros and cons

So what do you guys think, when does a problem call for using CQRS?

Best Solution

CQRS is not a pattern that encompasses the whole application.

It is a concept that builds on Domain Driven Design (DDD). And an important strategic concept of DDD is the so-called Bounded Context.

In a typical application there are multiple bounded contexts, any of which can be implemented the way it makes sense. For instance

  • User Management -> CRUD
  • Invoicing -> CRUD
  • Insurance Policy Management (the Core Domain) -> CQRS
  • ...

This probably doesn't answer your question but it might give a little more insight into the topic. To be honest, I don't think it can be answered at all without considering a project's specifics, and even then there is rarely something like a definite best practice.