Separation of Concerns

CQRS is a pattern that tells us to use different models for reading data and writing data.

1. Commands vs Queries

**Commands:** Actions that change the state of the system (Create, Update, Delete). They return nothing (or just an ID/Status). They focus on business rules and consistency.
**Queries:** Actions that read data. They return a value. They focus on performance and satisfying the UI's specific data needs.

2. Why separate them?

In a standard app, we use a single 'Repository' that returns Entities. But the UI often needs a 'View Model' that combines 5 different entities. By using CQRS, we can optimize our Read side (using Dapper or raw SQL for speed) without affecting our complex Write side (using EF Core and DDD for consistency).

3. Architect Insight

Q: "Does CQRS require two databases?"

Architect Answer: "NO. That is 'Physical CQRS'. You can start with 'Logical CQRS', where you simply have different classes for Commands and Queries but they both talk to the same SQL database. This still gives you 80% of the benefits (simplicity and clean code) without the 100% of the headache of keeping two databases in sync."