Skip to main content
skill CX Codex

clean-architecture · codewithmukesh — Claude Code skill for .NET layers

A skill that lays out .NET code across four projects, keeps dependencies pointing inward, and shows where use case handlers belong.

Install into Claude Code · Skills CLI (Vercel) All methods and platforms ↓
npx skills add codewithmukesh/dotnet-claude-kit --skill clean-architecture -a claude-code
Open on GitHub

What clean-architecture does

This skill covers Clean Architecture for .NET: Domain, Application, Infrastructure and Api as separate projects. Dependencies point inward, and the compiler enforces that through project references. Domain holds business rules as entity methods and knows nothing about databases or HTTP — just C# and .NET primitives.

You get code templates, not just prose. A minimal IAppDbContext abstraction instead of a repository layer, command and query handlers built on Mediator, validators with FluentValidation, entities with behaviour and a static Create factory. Infrastructure is treated as a plugin: EF Core, email senders and external APIs implement interfaces declared in Application or Domain, so swapping one out leaves business logic alone. The Api layer stays thin — endpoints only translate HTTP into use case calls.

The templates assume a specific stack: source-generated Mediator, FluentValidation, EF Core. Bring a different mediator library, or keep repositories on top of DbSet on purpose, and you will be rewriting the samples to fit.

What it helps with

  • split a .NET solution into Domain, Application, Infrastructure and Api
  • move business rules into entities instead of fat service classes
  • give each use case its own command or query handler
  • wire EF Core and external services through interfaces without touching logic
  • keep API endpoints free of business code

Example prompts for the agent

  • Scaffold a Clean Architecture project layout for orders
  • Add a CreateOrder command with its handler and validator
  • Rewrite this service as a use case handler using IAppDbContext

How to install clean-architecture

1Skills CLI (Vercel)

npx skills add codewithmukesh/dotnet-claude-kit --skill clean-architecture -a claude-code

2Manually: put the files in place

~/.claude/skills/clean-architecture/SKILL.md

Copy the whole skill folder; for one project use .claude/skills/clean-architecture/

Step by step, with commands for each platform: How to install skills in Claude Code: five ways

Questions about clean-architecture

How do I install clean-architecture in Claude?

Run npx skills add codewithmukesh/dotnet-claude-kit --skill clean-architecture -a claude-code. The skill file lands at ~/.claude/skills/clean-architecture/SKILL.md.

What does clean-architecture do?

It describes the four-project layout for .NET and supplies templates: the IAppDbContext abstraction, command and query handlers, validators, and entities with behaviour. The skill loads when you design layers or discuss dependency inversion.

Which stack does the skill assume?

The samples use source-generated Mediator, FluentValidation and EF Core. IAppDbContext is preferred over a repository, on the grounds that DbSet already plays that role.

Source text

SKILL.md · MIT
---
name: clean-architecture
description: >
  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.
---

# 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.cs
public interface IAppDbContext
{
    DbSet<Order> Orders { get; }
    DbSet<Product> Products { get; }
    Task<int> SaveChangesAsync(CancellationToken ct = default);
}

// Infrastructure/Persistence/AppDbContext.cs
public 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.cs
public 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.cs
public 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.cs
public 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.cs
internal 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.cs
public 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.cs
public 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.cs
public 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 handler
public 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 directly
order.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.cs
public 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 endpoint
app.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 case
app.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 functionality
public 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

| 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/ |

© codewithmukesh · MIT · codewithmukesh/dotnet-claude-kit

Similar skills

Everything for Backend and APIs →

clean-architecture by other authors comes first.

clean-architecture wondelai A skill that keeps business rules independent of framework and database by enforcing one rule: source code dependencies point inward. CX Codex +1 7,300installs clean-architecture giuseppe-trisciuoglio Guides Clean Architecture, hexagonal architecture and DDD patterns in Java 21+ Spring Boot 3.5+ projects. Use it when separating domain code from frameworks or refactoring coupled code. CX Codex +1 4,000installs clean-architecture pproenca A skill with 42 rules from Robert C. Martin's book: it tells the agent which way dependencies should point and where layer boundaries belong. CX Codex +1 2,000installs android-clean-architecture affaan-m Tells the agent how to split an Android or KMP project into layers: modules, dependency rules, UseCases, repositories, plus Room, SQLDelight and Ktor patterns. CX Codex +1 5,200installs dotnet-patterns affaan-m C# and ASP.NET Core architectural conventions for AI coding agents. Enforces patterns for dependency injection, immutability, async/await, and error handling. CX Codex +1 4,600installs migrate-dotnet10-to-dotnet11 dotnet Systematically migrates .NET 10 solutions to .NET 11. It updates target frameworks, bumps dependencies, and resolves C# 15 compiler and EF Core 11 breaking changes. CX Codex +1 3,400installs migrate-dotnet9-to-dotnet10 dotnet Walks a project from net9.0 to net10.0: updates TargetFramework, fixes build errors and works through breaking changes in .NET 10, C# 14, ASP.NET Core 10 and EF Core 10. CX Codex +1 3,400installs dotnet-fullstack-mentor official github A .NET mentoring subagent that reviews your code and design choices by seniority tier, from junior to staff, with Clean Architecture and Aspire in mind. ★ 40,418repo stars csharp official github A rule that pins Copilot to one C# style: naming, nullable types, formatting and ASP.NET Core patterns. Useful when the agent writes differently in every file. ★ 40,418repo stars

From the same set46

ddd A skill that teaches the agent Domain-Driven Design tactical patterns for .NET: aggregates, value objects, domain events, strongly-typed IDs and aggregate repositories. CX Codex +1 2,900installs verify Runs a .NET project check before review, covering builds, tests, security, formatting, and changed files. CX Codex +1 2,800installs code-review Multi-dimensional .NET code review: Roslyn MCP catches antipatterns and diagnostics, manual review covers the risky paths first. CX Codex +1 2,800installs project-setup Recommends .NET tech stack defaults for databases, auth, caching, and messaging. Helps pick stack defaults or review dependencies before writing code. CX Codex +1 2,800installs instinct-system Captures code patterns, user corrections, and project findings in separate stores. Use it when an agent needs to retain lessons from recurring work. CX Codex +1 2,800installs container-publish Builds OCI images straight from dotnet publish /t:PublishContainer, no Dockerfile involved. Useful when a .NET 10 app has to ship as a container and land in a registry. CX Codex +1 2,800installs workflow-mastery Workflow guide and configurations for .NET development in Claude Code. It introduces parallel sessions via git worktrees, verification loops, and context budgeting. CX Codex +1 2,800installs aspire Guides .NET Aspire setup for local service orchestration, resource wiring, and service discovery. Use it when working with AppHost or shared service defaults. CX Codex +1 2,800installs

Project sponsors

Companies that keep this analytics open
Gold sponsor

Impressions, clicks and code copies — open statistics. We keep the numbers public for the same reason NeBlask itself is public. Become a sponsor