Loading content
Command Query Responsibility Segregation (CQRS) (Command Query Responsibility Segregation) is an architectural approach that separates the responsibility for read and write operations in a system. This allows for better scalability and flexibility, as the two operations can be optimized independently. CQRS encourages the use of different models for read and…
Use this profile to understand the building block briefly, place it in the model, and switch to the 360° assessment when needed.
Theoretical construct: explains a term, principle, or mental model.
What organizes, connects, or makes decisions possible.
CQRS separates the model used for commands from the model used for queries so each side can be optimized for its own purpose.
CQRS grew out of command-query separation, domain-driven design, and the practical problem that a single CRUD model struggles to combine write rules, read views, and different representations in complex domains. Martin Fowler described the pattern in 2011 and noted that he first heard it from Greg Young. The core idea is to split update and read models; it is not a new database technology.
Think of two cooperating layers: the write side accepts commands, checks rules, and changes domain state. Those changes feed a separate read side, optimized for queries and presentation. Both sides may share one database or stay in sync through events; the read side is allowed to lag briefly behind.
A command expresses an intended state change and carries business intent, not just a data field.
A query reads data and does not change domain state.
The write side validates rules, coordinates changes, and protects consistency.
The read side stores projections prepared for display and querying.
After a change, the read side may be temporarily stale until synchronization catches up.
A bounded context can have its own models and rules; CQRS fits especially well in complex domains.
CQRS is most useful in complex domains, task-based user interfaces, and systems where read and write load differ significantly. Its benefit is separate optimization and clearer models, but the trade-off is extra coordination, more operational work, and often eventual consistency. For straightforward CRUD systems it is usually unnecessary; in practice it belongs only in well-scoped parts of a system.
Where this building block is located in the topic model.
No structure path available.
Explore how this building block connects to concepts, methods, technologies, and tools.
These sources establish the term and its professional meaning.
All direct connections of the current building block in a compact text view.
This classification shows where the building block typically matters, how demanding it is, and what kind of impact it has in the model.
The level within the organization (enterprise, domain, team) at which the AssetBlock is applied.