Clean Architecture for .NET applications. Covers the 4-project layout (Domain, Application, Infrastructure, Api), dependency inversion, use case handlers, domain entities with behavior, and infrastructure as a plugin. Load this skill when building a project with Clean Architecture, discussing layere

Clean Architecture Core Principles 1. Dependency inversion is the foundation — All dependencies point inward. Domain has zero project references. Application references only Domain. Infrastructure references Application and Domain. Api references all but depends on abstractions. The compiler enforces this via project references. 2. Domain owns the rules — Business logic lives in the Domain layer as entity methods, domain services, or specifications. The Domain layer has no knowledge of databases, HTTP, or any framework — only pure C and .NET primitives. 3. Use cases are the unit of work — Each use case (command or query) is a single class in the Application layer. It orchestrates domain objects, persists through abstractions, and returns a result. No "service" classes with 20 methods. 4. Infrastructure is a plugin — EF Core, external APIs, email senders, file storage — all live in Infrastructure and implement interfaces defined in Application or Domain. Swap implementations without touching business logic. 5. The API layer is thin — Endpoints map HTTP to use cases and use cases to HTTP responses. No business logic in endpoints. Patterns Project Layout DbContext Abstraction (Preferred Over Repository) Define a minimal interface in Application; implement in Infrastructure: Why IAppDbContext over IRepository? EF Core's DbSet already IS a repository. Adding another abstraction on top adds indirection without value in most cases. Use Case Handler (Command) Use Case Handler (Query) Domain Entity with Behavior Thin Endpoint Wiring (IEndpointGroup Auto Discovery) Every endpoint group implements IEndpointGroup and is auto discovered via app.MapEndpoints() . Program.cs never changes when adding new endpoints. See the minimal api skill for the full IEndpointGroup interface and EndpointExtensions setup. Infrastructure DI Registration Anti patterns Anemic Domain Model DbContext in Domain Layer Fat Endpoints Repository for Every Entity Decision Guide Scenario Recommendation When to use CA over VSA Medium+ domain complexity, long lived system, team familiar with layers When to add a Domain layer Business rules involve invariants across entity groups IAppDbContext vs repositories Prefer IAppDbContext; add repository only for complex reusable queries Mediator vs raw handlers in CA Mediator for pipeline behaviors (validation, logging); raw handlers for simplicity When to add Domain events When side effects (notifications, audit) should be decoupled from the main flow Evolving from VSA to CA When handlers start needing shared domain logic that does not belong in Common/

clean-architecture