Clean Architecture in .NET Explained (The Dependency Rule)

If you've ever upgraded EF Core and had to touch 300 files, or tried to unit-test a single business rule and realized you needed a running database first — you've already felt the problem Clean Architecture solves.

This is the short version. There's a full deep-dive (four layers, real .NET 8 code with EF Core + MediatR, the honest trade-offs, and the pragmatic 2-project version most teams actually ship) linked at the bottom, plus a video walkthrough.

The one rule

Clean Architecture has exactly one rule worth memorizing:

Source code dependencies can only point inward.

Picture concentric circles. Your business logic sits in the center and references nothing. The framework, the database, and the UI live on the outer rings and depend on the center — never the other way around. Invert the dependencies and everything else falls into place.

The four layers

• Domain — entities, value objects, and pure business rules. Zero framework code: no [Table], no [Key], no EF Core.
• Application — use cases (command/query handlers). It defines the interfaces it needs, like IOrderRepository and IClock.
• Infrastructure — the implementations: EF Core, HTTP clients, email, file system. It implements the interfaces Application declared.
• Presentation (Web/API) — thin controllers that validate input, dispatch to a use case, and format the response. No business logic.

The magic is the inversion: Application says what it needs, Infrastructure provides how, and the DI container wires them together at startup. The use case never references EF Core, so you can test it with a simple fake.

public class PlaceOrderHandler : IRequestHandler<PlaceOrderCommand, Guid>
{
    private readonly IOrderRepository _orders;
    private readonly IClock _clock;

    public PlaceOrderHandler(IOrderRepository orders, IClock clock)
    {
        _orders = orders;
        _clock = clock;
    }

    public async Task<Guid> Handle(PlaceOrderCommand cmd, CancellationToken ct)
    {
        var order = Order.Place(cmd.CustomerId, MapItems(cmd.Items), _clock.UtcNow);
        await _orders.AddAsync(order, ct);
        return order.Id;
    }
}

No DateTime.UtcNow, no HttpContext, no database. That handler is testable in milliseconds.

Enforced by the compiler

Split the solution into projects and the Dependency Rule enforces itself:

• Domain.csproj -> no references
• Application.csproj -> references Domain
• Infrastructure.csproj -> references Application + Domain
• Web.csproj -> references everything

If someone tries to using Microsoft.EntityFrameworkCore inside the Application project, the build fails. Architecture enforced by the compiler, not by code review.

When NOT to use it

It isn't free — more files, more indirection, a steeper onboarding curve. Skip it for CRUD admin tools, MVPs, and short-lived projects. Reach for it when you have real business rules, a team of 3+, and a multi-year lifetime.

---

📺 Video walkthrough: https://www.youtube.com/channel/UCop7DtrfDIzEgyLbQxKxB7g

📖 Full guide — complete .NET 8 code, the four layers in depth, common pitfalls, and the pragmatic version: https://prepstack.co.in/blog/clean-architecture-csharp-complete-guide