C.Q.R.S stands for Common Query Responsibility Segregation.

The goal of this pattern is to improve the performances of queries on business objects (i.e aggregates) and avoid any performance impact generated by the aggregates data manipulations.

To handle that, this pattern separates (segregation) the reads from the create/update/delete operations to the aggregates.

It also provides different views of the aggregates for the read operations, depending on the requirements.

See the drawing:

Domain model:

• Create/Update/Delete operations are handled on the Domain model by the Command Handler (here, we can also handle basic queries using primary keys and no join)
• The Domain model manages the Aggregates
• The Domain model is mapped to its own database
• The Domain model publish Domain Events when data is changed

Query model:

• The Query model handles the complex read operations
• The Query model is mapped to its own database, whatever its type, to better serve its purpose
• The Query model has an Event Handler, receiving the Domain Events
• It updates its database and maintains view for the complex query
• We can have several Query models for each type of complex query

---

Benefits:

• Decouple Create/Update/Delete operations from Read operations
• Ease joins in a microservices architecture when data is spread over different microservices

Drawbacks:

• Add complexity
• There maybe a lag between the Aggregates and the Views