Clean Architecture

codewithmukesh/dotnet-claude-kit/skills/clean-architecture

by codewithmukesh23300897f4d1No license754 starsListed Oct 8, 2026Updated Oct 8, 2026Repository updated 2 months ago

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 layered architecture, dependency inversion, use cases, or when the architecture-advisor recommends Clean Architecture.

Instructions only

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

src/  MyApp.Domain/    Entities/      Order.cs                    # Entity with behavior      OrderItem.cs    Enums/      OrderStatus.cs    Exceptions/      DomainException.cs          # Base domain exception    Interfaces/      IOrderRepository.cs         # Only if query needs go beyond DbSet    Common/      Entity.cs                   # Base entity with Id      Result.cs                   # Result pattern type
  MyApp.Application/    Common/      Behaviors/        ValidationBehavior.cs     # Mediator pipeline behavior      Interfaces/        IAppDbContext.cs           # DbContext abstraction (preferred over repository)    Orders/      Commands/        CreateOrder/          CreateOrderCommand.cs          CreateOrderHandler.cs          CreateOrderValidator.cs      Queries/        GetOrder/          GetOrderQuery.cs          GetOrderHandler.cs          OrderDto.cs
  MyApp.Infrastructure/    Persistence/      AppDbContext.cs              # Implements IAppDbContext      Configurations/        OrderConfiguration.cs      Migrations/    Services/      EmailSender.cs               # Implements IEmailSender from Application    DependencyInjection.cs         # AddInfrastructure extension
  MyApp.Api/    Endpoints/      OrderEndpoints.cs            # Thin, maps HTTP ↔ use cases    Program.cs

DbContext Abstraction (Preferred Over Repository)

Define a minimal interface in Application; implement in Infrastructure:

csharp
// Application/Common/Interfaces/IAppDbContext.cspublic interface IAppDbContext{    DbSet<Order> Orders { get; }    DbSet<Product> Products { get; }    Task<int> SaveChangesAsync(CancellationToken ct = default);}
// Infrastructure/Persistence/AppDbContext.cspublic class AppDbContext(DbContextOptions<AppDbContext> options)    : DbContext(options), IAppDbContext{    public DbSet<Order> Orders => Set<Order>();    public DbSet<Product> Products => Set<Product>();
    protected override void OnModelCreating(ModelBuilder modelBuilder)    {        modelBuilder.ApplyConfigurationsFromAssembly(typeof(AppDbContext).Assembly);    }}

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)

csharp
// Application/Orders/Commands/CreateOrder/CreateOrderCommand.cspublic record CreateOrderCommand(    string CustomerId,    List<OrderItemDto> Items) : IRequest<Result<Guid>>;
public record OrderItemDto(string ProductId, int Quantity, decimal UnitPrice);
// Application/Orders/Commands/CreateOrder/CreateOrderHandler.cs — uses Mediator (source-generated, MIT)internal sealed class CreateOrderHandler(    IAppDbContext db,    TimeProvider clock) : IRequestHandler<CreateOrderCommand, Result<Guid>>{    public async ValueTask<Result<Guid>> Handle(CreateOrderCommand request, CancellationToken ct)    {        var order = Order.Create(            request.CustomerId,            request.Items.Select(i => new OrderItem(i.ProductId, i.Quantity, i.UnitPrice)),            clock.GetUtcNow());
        db.Orders.Add(order);        await db.SaveChangesAsync(ct);
        return Result.Success(order.Id);    }}
// Application/Orders/Commands/CreateOrder/CreateOrderValidator.cspublic class CreateOrderValidator : AbstractValidator<CreateOrderCommand>{    public CreateOrderValidator()    {        RuleFor(x => x.CustomerId).NotEmpty();        RuleFor(x => x.Items).NotEmpty();        RuleForEach(x => x.Items).ChildRules(item =>        {            item.RuleFor(x => x.ProductId).NotEmpty();            item.RuleFor(x => x.Quantity).GreaterThan(0);            item.RuleFor(x => x.UnitPrice).GreaterThan(0);        });    }}

Use Case Handler (Query)

csharp
// Application/Orders/Queries/GetOrder/GetOrderQuery.cspublic record GetOrderQuery(Guid OrderId) : IRequest<Result<OrderDto>>;
public record OrderDto(Guid Id, string CustomerId, decimal Total, string Status, DateTimeOffset CreatedAt);
// Application/Orders/Queries/GetOrder/GetOrderHandler.csinternal sealed class GetOrderHandler(IAppDbContext db) : IRequestHandler<GetOrderQuery, Result<OrderDto>>{    public async ValueTask<Result<OrderDto>> Handle(GetOrderQuery request, CancellationToken ct)    {        var order = await db.Orders            .Where(o => o.Id == request.OrderId)            .Select(o => new OrderDto(o.Id, o.CustomerId, o.Total, o.Status.ToString(), o.CreatedAt))            .FirstOrDefaultAsync(ct);
        return order is not null            ? Result.Success(order)            : Result.Failure<OrderDto>("Order not found");    }}

Domain Entity with Behavior

csharp
// Domain/Entities/Order.cspublic class Order : Entity{    private readonly List<OrderItem> _items = [];
    private Order() { } // EF Core
    public string CustomerId { get; private set; } = null!;    public OrderStatus Status { get; private set; }    public decimal Total { get; private set; }    public DateTimeOffset CreatedAt { get; private set; }    public IReadOnlyList<OrderItem> Items => _items.AsReadOnly();
    public static Order Create(string customerId, IEnumerable<OrderItem> items, DateTimeOffset now)    {        var order = new Order        {            Id = Guid.CreateVersion7(),            CustomerId = customerId,            Status = OrderStatus.Pending,            CreatedAt = now        };
        foreach (var item in items)            order.AddItem(item);
        return order;    }
    public void AddItem(OrderItem item)    {        _items.Add(item);        Total = _items.Sum(i => i.Quantity * i.UnitPrice);    }
    public Result Cancel()    {        if (Status is not OrderStatus.Pending)            return Result.Failure("Only pending orders can be cancelled");
        Status = OrderStatus.Cancelled;        return Result.Success();    }}

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.

csharp
// Api/Endpoints/OrderEndpoints.cspublic sealed class OrderEndpoints : IEndpointGroup{    public void Map(IEndpointRouteBuilder app)    {        var group = app.MapGroup("/api/orders").WithTags("Orders");
        group.MapPost("/", CreateOrder)            .WithName("CreateOrder");
        group.MapGet("/{id:guid}", GetOrder)            .WithName("GetOrder");
        group.MapGet("/", ListOrders)            .WithName("ListOrders");    }
    private static async Task<IResult> CreateOrder(        CreateOrderCommand command, ISender sender, CancellationToken ct)    {        var result = await sender.Send(command, ct);        return result.IsSuccess            ? TypedResults.Created($"/api/orders/{result.Value}", result.Value)            : result.ToProblemDetails();    }
    private static async Task<IResult> GetOrder(        Guid id, ISender sender, CancellationToken ct)    {        var result = await sender.Send(new GetOrderQuery(id), ct);        return result.IsSuccess            ? TypedResults.Ok(result.Value)            : TypedResults.NotFound();    }
    private static async Task<IResult> ListOrders(        [AsParameters] ListOrdersQuery query, ISender sender, CancellationToken ct)    {        var result = await sender.Send(query, ct);        return TypedResults.Ok(result);    }}

Infrastructure DI Registration

csharp
// Infrastructure/DependencyInjection.cspublic static class DependencyInjection{    public static IServiceCollection AddInfrastructure(        this IServiceCollection services,        IConfiguration config)    {        services.AddDbContext<AppDbContext>(options =>            options.UseNpgsql(config.GetConnectionString("DefaultConnection")));
        services.AddScoped<IAppDbContext>(sp => sp.GetRequiredService<AppDbContext>());
        return services;    }}

Anti-patterns

Anemic Domain Model

csharp
// BAD — entity is just a data bag, all logic in handlerpublic class Order{    public Guid Id { get; set; }    public string CustomerId { get; set; } = null!;    public decimal Total { get; set; }    public List<OrderItem> Items { get; set; } = [];}
// Handler sets everything directlyorder.Total = order.Items.Sum(i => i.Quantity * i.UnitPrice);order.Status = OrderStatus.Pending;
// GOOD — entity encapsulates its own rules (see Domain Entity pattern above)var order = Order.Create(customerId, items, clock.GetUtcNow());

DbContext in Domain Layer

csharp
// BAD — Domain references EF Core// Domain/Services/OrderService.cspublic class OrderService(AppDbContext db) { } // Domain depends on Infrastructure!
// GOOD — Domain defines interfaces, Infrastructure implements// Domain/Interfaces/IOrderRepository.cs (only if you need query abstraction beyond DbSet)// Application/Common/Interfaces/IAppDbContext.cs (preferred)

Fat Endpoints

csharp
// BAD — business logic in the endpointapp.MapPost("/orders", async (CreateOrderRequest req, AppDbContext db) =>{    var order = new Order { CustomerId = req.CustomerId };    foreach (var item in req.Items)    {        order.Items.Add(new OrderItem { ProductId = item.ProductId, Quantity = item.Quantity });    }    order.Total = order.Items.Sum(i => i.Quantity * i.UnitPrice);    db.Orders.Add(order);    await db.SaveChangesAsync();    return TypedResults.Created($"/orders/{order.Id}", order);});
// GOOD — endpoint delegates to a use caseapp.MapPost("/orders", async (CreateOrderCommand command, ISender sender, CancellationToken ct) =>{    var result = await sender.Send(command, ct);    return result.IsSuccess        ? TypedResults.Created($"/orders/{result.Value}", result.Value)        : result.ToProblemDetails();});

Repository for Every Entity

csharp
// BAD — repository per entity duplicates DbSet functionalitypublic interface IOrderRepository { Task<Order?> GetByIdAsync(Guid id); }public interface IProductRepository { Task<Product?> GetByIdAsync(Guid id); }public interface ICustomerRepository { Task<Customer?> GetByIdAsync(Guid id); }
// GOOD — use IAppDbContext with DbSet<T> directly// Only create a repository interface when you have complex query logic// that you want to test in isolation or reuse across multiple use cases

Decision Guide

ScenarioRecommendation
When to use CA over VSAMedium+ domain complexity, long-lived system, team familiar with layers
When to add a Domain layerBusiness rules involve invariants across entity groups
IAppDbContext vs repositoriesPrefer IAppDbContext; add repository only for complex reusable queries
Mediator vs raw handlers in CAMediator for pipeline behaviors (validation, logging); raw handlers for simplicity
When to add Domain eventsWhen side effects (notifications, audit) should be decoupled from the main flow
Evolving from VSA to CAWhen handlers start needing shared domain logic that does not belong in Common/

Source and attribution

Source:codewithmukesh/dotnet-claude-kitinskills/clean-architectureat commit2330089

License: No license

Content belongs to its original authors. SourceWeft indexes it from a public repository.

Report or request removal

More from codewithmukesh/dotnet-claude-kit

Wrap Up

codewithmukesh

Captures end-of-session work, pending tasks and learnings into a handoff file, and reloads it at session start.

Productivity & Workflow754updated 2 months ago

Workflow Mastery

codewithmukesh

Claude Code workflow mastery for .NET developers. Covers parallel execution with git worktrees, plan mode strategy, verification loops, auto-formatting hooks, permission setup for dotnet CLI, prompting techniques, subagent patterns, and context discipline — token budget management, MCP-first navigation, lazy loading, and subagent isolation — all adapted for the .NET ecosystem. Load this skill when setting up Claude Code for a .NET project, optimizing workflows, running parallel sessions, when context is running low or sessions feel sluggish, when exploring a large codebase efficiently, or when the user mentions "productivity", "workflow", "parallel", "worktree", "plan mode", "permissions", "hooks", "10x", "setup Claude Code", "speed up development", "context", "tokens", "budget", "running out of context", "too many files", or "large codebase". Inspired by tips from Boris Cherny (creator of Claude Code) and the Anthropic team.

Awaiting classification754updated 2 months ago

Vertical Slice

codewithmukesh

Guides .NET developers in structuring applications with Vertical Slice Architecture, covering feature folders, endpoint grouping and handler patterns.

Software Development754updated 2 months ago

Testing

codewithmukesh

Testing strategy for .NET 10 applications. Covers xUnit v3, WebApplicationFactory for integration tests, Testcontainers for real database testing, Verify for snapshot testing, and the AAA pattern. Load this skill when writing tests, setting up test infrastructure, reviewing test coverage, or when the user mentions "test", "xUnit", "WebApplicationFactory", "Testcontainers", "integration test", "unit test", "bUnit", "snapshot test", "Verify", "test coverage", "AAA pattern", "WireMock", or "FakeTimeProvider".

Awaiting classification754updated 2 months ago

Tdd

codewithmukesh

Guided test-driven development workflow for .NET 10 using xUnit v3, WebApplicationFactory, Testcontainers, and Verify snapshots. Follows the strict red-green-refactor cycle. Use when: "TDD", "test-driven", "let's TDD this", "red green refactor", "write the test first", or when building a feature with clear acceptance criteria.

Awaiting classification754updated 2 months ago

Spec

codewithmukesh

Turns a vague feature idea into an agreed, persisted specification file through structured questioning rounds.

Productivity & Workflow754updated 2 months ago