Sign in to track progress and bookmarks.
Command Query Responsibility Segregation (CQRS) says that the model used for **Writing** data should be different from the model used for **Reading** data.
Optimized for business rules and consistency. This is where your DDD Aggregates live. It usually uses a relational database like SQL Server to ensure ACID compliance.
Optimized for the UI. No complex joins. No business logic. Often uses a NoSQL DB like **Elasticsearch** or **Redis** where the data is already pre-formatted for display. This makes 'Read' performance blazing fast, regardless of how complex the 'Write' logic is.
In .NET, we use the **MediatR** library to implement CQRS. It decouples your controllers from your business logic. The controller just sends a 'Command' or 'Query' to MediatR, and MediatR finds the one specific 'Handler' to process it. This leads to **Highly Testable** and **Thin Controllers**.
Q: "Do I ALWAYS need separate databases for CQRS?"
Architect Answer: "No. You can start with a single database and use CQRS to separate your **Code**. Use one model for updates and an 'AutoMapper' or 'Dapper' projection for reads. Only move to separate databases (and the resulting eventual consistency) when you've hit a performance bottleneck that can't be solved with indexing."
Quizzes linked to this course—pass to earn certificates.
On this page
1. The "Write side" (Commands) 2. The "Read side" (Queries) 3. MediatR: The Glue 4. Interview Mastery