.NET Clean Architecture - Honest Opinion

Clean Architecture has become the default answer to almost every .NET project, and that’s a problem.

Too often it means four or five projects, endless interfaces, repositories wrapping EF Core, DTOs for everything, and a simple feature spread across a dozen files. Instead of making development easier, it introduces ceremony that slows everyone down.

The irony is that modern .NET already provides many of the abstractions people try to abstract again. EF Core is already a repository and unit of work. ASP.NET Core already promotes dependency injection. Adding another layer of wrappers often provides little value while making the code harder to navigate.

The usual justification is “future-proofing” or “testability.” In reality, many applications never swap databases or persistence technologies, and integration tests with real infrastructure have become much easier than maintaining hundreds of mocked unit tests.

For most CRUD applications, a well-structured modular project is easier to understand and easier to maintain than a textbook Clean Architecture.