CQRS in .NET: when to use it, trade‑offs
What is CQRS (in one line) Separate the write side (commands that change state) from the read side (queries that return data), so each can optimize independently. When to use CQRS Read/write needs are very different: Reads are hot and need tailored projections, denormalized views, caching, or a different store. Writes need strong validation, invariants, and transactions. Performance and scaling: Reads outnumber writes by a lot (10×–100×), and you want to scale/read-optimize without complicating write logic. UX wants different shapes than your domain: E.g., “Order with line items and fulfillment status by customer” needs a custom read model that doesn’t match your normalized write schema. Complex domains: Clearer boundaries and testing by separating write rules (invariants) from read concerns (reporting, search). Event-driven systems: You already publish events and can build read models/projections asynchronously. When not to use CQRS ...