MediatR & CQRS in .NET
- As .NET systems grow, most complexity doesnโt come from features. It comes from ๐๐ฅ๐ฎ๐ซ๐ซ๐๐ responsibilities.
- Thatโs why I use MediatR + CQRS โ not as patterns, but as ๐ ๐ฎ๐๐ซ๐๐ซ๐๐ข๐ฅ๐ฌ.
What this approach enforces:
- Controllers express intent only
- MediatR owns request flow and cross-cutting concerns
- Queries read, Commands write โ never both
- Each request maps to exactly one handler
- Read and write models evolve independently
- The result is code thatโs easier to reason about, test, and change under pressure.
Where CQRS actually helps:
- Complex domains
- Read-heavy workloads
- Performance-sensitive systems
- Clear separation between consistency and speed
Where not to use CQRS:
- Simple CRUD applications
- Small teams unfamiliar with the pattern
- Systems where eventual consistency adds risk, not value
- CQRS doesnโt remove complexity; It ๐จ๐ซ๐ ๐๐ง๐ข๐ณ๐๐ฌ ๐ข๐ญ โ when the problem is big enough to deserve it.