Open ten different ".NET Clean Architecture" repos on GitHub and you'll find ten different folder structures: Domain, Application, Infrastructure, Presentation. Four neat layers, dependencies pointing inward, a tidy diagram in the README. And yet plenty of these codebases are just as hard to change as the "messy" ones they replaced.
The folder structure isn't the architecture
Clean Architecture, as Robert Martin describes it, is about one rule: dependencies point inward, toward the domain, never outward toward frameworks or infrastructure. That's it. Everything else — the specific layer names, the project structure, the number of projects in your .sln — is implementation detail.
The mistake is treating the folder structure as the goal. You can have four perfectly named layers and still have:
- Domain entities with public setters that any layer can mutate freely.
- "Application" services that are really just thin wrappers around Entity Framework calls.
- Business rules leaking into controllers because "it's just this one validation."
None of that shows up in a dependency diagram, but all of it defeats the purpose.
What actually matters
If I had to reduce it to a short checklist, it's this:
- Can you test your domain logic without spinning up a database? If not, your domain depends on infrastructure, no matter what the folder says.
- Could you swap your database, your UI framework, or your message broker without touching business rules? If changing Entity Framework to Dapper means rewriting domain logic, the dependency rule isn't actually being enforced.
- Does a new developer need to read five files across three layers to understand one business rule? That's usually a sign the architecture is organized around technical concerns instead of the actual domain.
The boring conclusion
Clean Architecture is a constraint, not a structure. It's entirely possible to violate it inside a perfectly organized folder tree, and it's possible to honor it in a single project with no folders at all (though I wouldn't recommend that for a team). Before reaching for another layer, ask whether you're protecting the dependency rule or just decorating around it.
