A common context for Command-Query Responsibility Segregation (CQRS) is a collaborative domain with multiple users working on the same set of data, Udi Dahan explained when discussing CQRS in an interview. For Udi, an authority on service-oriented architecture and creator of NServiceBus, CQRS is an approach or a style of thinking, more than a pattern. When called a pattern it often becomes associated with only the solution part, the context part is too often forgotten, despite it being the most important part when discussing CQRS.
A lot of applications contain a business domain that is relatively simple with a user working on a piece of data with no one else working on the same data, meaning the user expects to directly read what they just wrote. Working with CQRS, and eventual consistency, in such a domain means you will be working hard trying to recreate what the end user really wants to see, an example of how important the context is working with CQRS and when it’s not suitable. In contrast, when in a collaborative domain with users modifying some data they have no way of knowing whether somebody else has also modified the same data and therefore their expectation of what they will be reading is different than in a single-user domain.
Usually collaborative domains tend to be large in number of records, each relatively small but resulting in a large data volume, with a lot of history and interaction. A classic example is the domain of inventory, with shipments coming in, purchases going out, and with questions like how large the stock is, how much can be purchased and delivery time for an order. A more high volume example is stock purchases, a domain that from the ground up is designed for handling large volumes and modelled for working with multiple parties.
Udi specifically notes that the intent never has been to build CQRS systems. CQRS will never be applicable to a whole application; part of it may be for single user doing CRUD, with other parts more collaborative and suitable for CQRS.
Today Udi puts a much stronger emphasize on data modelling. He thinks that ORMs has done some harm in making developers focusing entirely on their in-memory object model, not caring at all about the actual data model behind the scene. He states that in a collaborative domain you have to work the other way around, starting with the data model. He sees himself as a DDD guy but believes that sometimes you have to wait with the domain model and focus on the data modelling. In his experience this very often the leads to a data model being simple enough to question if a domain model is really needed.