What is Clean Architecture and why use it?

Clean Architecture organizes a codebase so that business logic is independent of frameworks, databases, UI, and third-party libraries. The result: code you can unit-test in milliseconds, that survives framework rewrites, and where each layer has one obvious job.

It was named by Robert C. Martin (Uncle Bob) in 2012, but the same idea exists under other names:

• Hexagonal / Ports & Adapters (Alistair Cockburn, 2005)
• Onion Architecture (Jeffrey Palermo, 2008)

All three describe the same structure with different visual metaphors. The .NET community usually says "Clean Architecture".

The one rule

Source code dependencies can only point inward.

That's the whole pattern in one sentence. Every other rule follows from it.

The four layers (inside → out)

   Domain  →  Application  →  Infrastructure  →  Presentation
   ──────     ───────────     ──────────────     ────────────
   Pure       Use cases +     EF Core, HTTP      Controllers,
   business   interfaces      clients, email,    Razor, Minimal
   rules.     defining what   queues, file       APIs. Thin
              Infra MUST      system, third-     glue.
              implement.      party APIs.

Dependencies flow INWARD only:

• Domain references nothing
• Application references Domain
• Infrastructure references Application + Domain
• Presentation references Application (and optionally Infrastructure for DI wiring)

Why use it

1. Testable without infrastructure — your business logic runs in unit tests with no DB, no HTTP, no Docker. Hundreds of tests in seconds.
2. Framework-independent — upgrade EF Core 7 → 9, swap MSSQL → Postgres, swap MVC → Minimal APIs without touching domain code.
3. Clear ownership — every line of code has exactly one obvious home.
4. Multiple delivery channels — same use case serves HTTP, queue consumer, gRPC, cron. Wire at the composition root.
5. Compile-time enforcement — the project references prevent dependency violations. Junior tries using Microsoft.EntityFrameworkCore; in Domain.csproj → build fails.

Real-world fit

• ✅ E-commerce, banking, fintech, insurance, SaaS with rich business rules
• ❌ Simple CRUD admin tools, MVPs, single-dev side projects, gateway/proxy services

Concrete payoff

In a typical "fat controller" .NET app, testing a business rule means spinning up a test database + WebApplicationFactory. One test = 2-3 seconds.

In Clean Architecture, the same test is:

var handler = new PlaceOrderHandler(new FakeOrderRepository(), new FixedClock(now));
var result = await handler.Handle(cmd, default);
Assert.Equal(OrderStatus.Placed, result.Status);

5 milliseconds. The first time you write a 50-test feature in 10 minutes instead of an hour, the upfront cost has paid back.

What it is NOT

• Not a framework. There's no NuGet package called "Clean Architecture".
• Not the same as DDD (Domain-Driven Design). DDD is about modeling. Clean Architecture is about file organization. They're complementary.
• Not the same as N-tier. N-tier separates UI / Business / Data horizontally; Clean Architecture inverts dependencies so Business doesn't depend on Data.

Interview-grade summary

"Clean Architecture is the .NET convention for organising code so business logic depends on nothing — not your ORM, not your web framework, not your third-party libraries. The Dependency Rule (deps point inward) is enforced by the compiler via project references. It pays off when the app has real business rules and a multi-year lifetime. It's overhead for simple CRUD apps and MVPs."