Clean architecture has become close to a default recommendation for new .NET projects, and for good reason: separating domain logic from infrastructure concerns makes a codebase easier to test and easier to change later. It also adds real ceremony: more projects, more interfaces, more indirection between a request coming in and a database row being written. That ceremony is worth it in some situations and genuine overhead in others.
What Clean Architecture Actually Buys You
The core promise is that your business rules do not know or care whether they are backed by SQL Server, Cosmos DB, or an in memory list during tests. That independence pays off clearly in a few situations.
Complex domain logic that changes often. A quality assurance system tracking parts through a multi stage automotive supply chain, with rules that shift as regulations and supplier agreements change, benefits enormously from having that logic isolated in a domain layer that can be tested without spinning up a database.
Multiple entry points into the same logic. If the same business rules need to run from a web API, a background job, and an internal admin tool, clean architecture stops you from duplicating that logic three times or coupling it awkwardly to one specific host.
Long project lifespans with changing infrastructure. If you genuinely expect to swap a database technology, or add a second one, in the next few years, the abstraction pays for itself when that day arrives.
Where It Becomes Overhead
Small CRUD focused applications. An internal tool that reads and writes fairly simple records does not need four layers of indirection to do it. The extra projects and interfaces add friction without adding testability that matters, because there is not much business logic to isolate in the first place.
Teams new to the pattern under time pressure. Clean architecture has a real learning curve. A team unfamiliar with it, working against a tight deadline, often ends up with the structure but not the discipline: dependencies leak across layers anyway, and you are left paying the complexity cost without the benefit.
Prototypes and proof of concepts. If there is a real chance the whole approach gets thrown away after validation, invest the architecture effort later, once you know the product is worth building properly.
A Practical Middle Ground
src/
Domain/ // entities, business rules, no dependencies
Application/ // use cases, orchestration
Infrastructure/ // EF Core, external APIs
Api/ // minimal API endpoints
For most greenfield .NET projects that are not trivial CRUD, this four folder structure gives you real separation without the heavier ceremony some clean architecture templates default to, such as separate projects per layer with their own dependency graphs. Start with folders inside one project. Split into separate projects only once the codebase is large enough that build times or team boundaries genuinely require it.
The Decision in One Question
Before adopting clean architecture on a new build, ask honestly: is the domain logic in this application complex enough, and likely to change often enough, that isolating it from infrastructure will save real time over the life of the project? If yes, the structure earns its keep. If the honest answer is that this is mostly a data entry and reporting tool, a simpler, more direct architecture will get you to production faster and will not cost you anything meaningful in maintainability later.
Architecture decisions made out of habit, rather than out of an honest read on the specific project, are one of the most common sources of wasted effort on greenfield builds.
