When to use the CQRS design pattern?
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.
Well CQRL critics may say that CQRS is complicated and that might be true.
Of course, it's adding overhead developing a simple CRUD application in the CQRS style, so I'd consider using CQRS only in the following cases:
- Large team - You can split development tasks between people easily if you have chosen CQRS architecture. Your top people can work on domain logic leaving usual stuff to less skilled developers.
- Difficult business logic - CQRS forces you to avoid mixing domain logic and infrastructural operations.
- Scalability matters - With CQRS you can achieve great read and write performance, command handling can be scaled out on multiple nodes and as queries are read-only operations they can be optimized to do fast read operations.
When you have a complex or hard business domain and:
- with event sourcing; you want a nice way of testing logic
- with event sourcing; you want to prove your behaviours through testing and reasoning
- you have multiple clients, or consumers, of your domain service (not just single web server)
OR you have users that need to act on common data:
- and you want to formalize the data merge concepts of your domain
- or you want to apply logic for merging events
OR you have scalability requirements:
- you apply the pattern as a denormalization pattern that removes bottlenecks
- you want to scale horizontally and not vertically
OR you have performance problems (other side of scalability):
- e.g. you need to migrate your architecture towards an event driven architecture - CQRS as a pattern is a good stepping stone.
OR you have a team that is physically disjunct:
- e.g. parts of your team is in another country
- or it's hard to get face-to-face communication, so you want to decouple the read models from the write-side of things (sagas, domain, CRUD)
It's not CQRS that's overly complicated, it's computers that are.
When to use the CQRS design pattern?
The CQRS architecture pattern could be used when it is difficult to query from repositories all the data that users need to view. This is especially true when UX design creates views of data that cuts across several aggregate types and instances. The more sophisticated your domain, the more this tends to be true.
When it is unsuitable to compromise on UX design, using CQRS attempts to mitigate the problems associated with other solutions, such as:
- requiring clients to use multiple repositories to retrieve all aggregate instances; or
- the design of specialized finders on various repositories to gather disjointed data using a single query.
To summarize: Use CQRS when its difficult to query from repositories data users need to view, which tend to happen the more sophisticated your domain is.
In real world scenario CQRS might be useful when you have front end/web service client which needs lots of data from multiple domains and retrieval of these data from database takes long time.
In such case you might consider creation of separate read model which will be faster to develop and might have faster execution time.