CQRS - When to use and why to use?

In summary, CQRS is useful and recommended in complex domain scenarios or in high-performance applications.

Paraphrasing Microsoft documentation when compared to the conventional CRUD model:

  

Compared to the single data model used in systems based   in CRUD, the use of separate update and query templates for   data in CQRS-based systems simplifies the design and   Implementation. However, a disadvantage is that, unlike   CRUD projects, the CQRS code can not be generated automatically   using scaffold mechanisms.

So one of the biggest advantages is the performance improvement in complex applications and one of the biggest drawbacks is the possible increase in complexity of the code that represents the model. However, CQRS is not recommended in all scenarios.

Recommended Scenarios:

• Collaborative domains with parallel operations in the same data model.
• Task-based user interfaces divided into multi-step
• Systems where the amount of data read is much larger than the write number
• Scenarios where the business rule changes frequently
• Integration between systems, where failure of one can not stop the other

Scenarios not recommended:

• Domains with simple business rules (for example, CRUD-based applications)

Furthermore, according to Martin Fowler's recommendations, the CQRS standard should be applied to parts of a system and not to the whole system. Attempting to implement this pattern on a system whose complexity is not compatible will only greatly reduce the productivity and complexity of development. Also consider the team's experience with DDD, as an immature team regarding the correct implementation of rich domains can be disastrous in attempting to implement the CQRS.

There is no difference between implementing this standard with .NET Core or another framework or language, considerations in using (or not) are not limited to a technical issue.

Sources:

Microsoft Documentation: link

Martin Fowler: link