CQRS in .NET: When It Makes Sense and When It Doesn't
Every .NET codebase I've worked on that eventually adopted CQRS arrived there the same way: through a service class that nobody wanted to open anymore. You know the one. It starts as JobService . It has CreateJob , GetJobById , and UpdateJob . Reasonable. Six months later it has GetJobForAdminDashboard , GetJobForPublicListing , GetJobWithApplicationCounts , ArchiveExpiredJobs , and a constructor taking nine dependencies because one method needs the email sender, another needs the search indexer, and a third needs the payment client. The file is 1,400 lines. Two of the read methods load full EF Core entities with four Include calls when all they need is a title and a salary range. Somebody added a bool sendNotification = true parameter in 2023 and now four call sites pass false . Nothing here is a disaster. That's exactly the problem. It degrades slowly enough that no single commit looks wrong. At some point someone says "we should look at CQRS," and the team eit...