I'm trying to move away from "Fat Controllers" and messy service layers. What is the standard project structure for Clean Architecture in the .NET world today? How do you properly separate the Domain, Application, Infrastructure, and Presentation layers while keeping Dependency Injection clean?
3 answers
Clean Architecture is all about the "Dependency Rule"—dependencies only point inward. Your Domain layer (entities, specifications) is the core and has no dependencies. The Application layer (interfaces, DTOs, MediatR handlers) depends only on the Domain. The Infrastructure layer (EF Core, Email services, Cloud SDKs) implements those interfaces. Finally, the Presentation (Web API) is the entry point. A popular way to keep this clean in .NET is using the MediatR library for the CQRS pattern. This keeps your controllers extremely thin—usually just one line to send a command or query—making the whole system incredibly testable.
Does this architecture add too much boilerplate for smaller projects? It feels like I'm creating four different classes just to save a single user record to a database.
I've found that using the "Vertical Slice" architecture is a great middle ground. It keeps all code for a single feature together, which reduces the constant jumping between projects.
Vertical Slicing is gaining a lot of traction lately! It definitely solves the "too many projects" frustration while still maintaining high cohesion and low coupling.
Brandon, you’re absolutely right that it adds overhead. For a small "Internal Tool" or a simple CRUD app, Clean Architecture is definitely overkill. However, for an enterprise system that will live for 5+ years with a rotating team of developers, that "boilerplate" is what prevents the code from turning into spaghetti. It makes it much easier to swap out a SQL database for a NoSQL one, or change an email provider, without touching your core business logic. Choose the architecture based on the project's expected lifespan and complexity.