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."