К основному содержанию
скилл CX Codex

clean-architecture · codewithmukesh — скилл для Claude Code: слои в .NET

Скилл для .NET-проектов: раскладывает код по четырём слоям, следит за направлением зависимостей и подсказывает, где живут use case-хендлеры.

Установить в Claude Code · Через Skills CLI (Vercel) Все способы и платформы ↓
npx skills add codewithmukesh/dotnet-claude-kit --skill clean-architecture -a claude-code
Открыть на GitHub

Что делает clean-architecture

Скилл описывает Clean Architecture для .NET: четыре проекта — Domain, Application, Infrastructure, Api. Зависимости смотрят внутрь, и это проверяет сам компилятор через ссылки между проектами. Domain не знает ни о базе, ни об HTTP, только C# и примитивы .NET.

Внутри — готовые шаблоны кода: абстракция IAppDbContext вместо репозитория, команды и запросы с хендлерами на Mediator, валидаторы на FluentValidation, сущности с поведением и фабричным методом Create. Инфраструктура подаётся как плагин: EF Core, отправка почты, внешние API реализуют интерфейсы из Application или Domain, поэтому подмена не задевает бизнес-логику. API-слой тонкий, эндпоинты только переводят HTTP в вызовы use case.

Скилл опирается на конкретный стек: Mediator с генерацией исходников, FluentValidation, EF Core. Если в проекте другая медиатор-библиотека или вы сознательно держите репозитории поверх DbSet, шаблоны придётся переписывать под себя.

Какие задачи решает

  • разложить .NET-решение по слоям Domain, Application, Infrastructure и Api
  • вынести бизнес-правила в сущности вместо сервисов с десятком методов
  • описать use case отдельным классом-хендлером на команду или запрос
  • подключить EF Core и внешние сервисы через интерфейсы, не трогая логику
  • сделать эндпоинты тонкими, без бизнес-кода внутри

Примеры запросов агенту

  • Создай структуру проекта по Clean Architecture для заказов
  • Добавь команду CreateOrder с хендлером и валидатором
  • Перепиши этот сервис в use case-хендлер с IAppDbContext

Как установить clean-architecture

1Через Skills CLI (Vercel)

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

2Вручную: положить файлы

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

Папка скилла целиком; для одного проекта — .claude/skills/clean-architecture/

По шагам, с командами для каждой платформы: Как установить скилл в Claude Code: пять способов

Из того же набора46

ddd Скилл для тактических паттернов Domain-Driven Design в .NET: агрегаты, value objects, доменные события, строго типизированные ID и репозитории для агрегатов. CX Codex +1 2 900установок verify Запускает проверку .NET-проекта перед ревью: сборку, тесты, безопасность, форматирование и анализ изменений. CX Codex +1 2 800установок code-review Многоуровневое ревью .NET-кода: Roslyn MCP ищет антипаттерны и диагностику, а ручная проверка идёт по зонам риска. CX Codex +1 2 800установок project-setup Подбирает стек технологий для проектов на .NET: базу данных, авторизацию, кеш и очереди. Пригодится на старте архитектурного выбора или ревизии зависимостей. CX Codex +1 2 800установок instinct-system Фиксирует паттерны, правки пользователя и находки в файлах проекта. Нужен, когда агенту надо учиться на повторяющихся решениях. CX Codex +1 2 800установок container-publish Собирает OCI-образы прямо из dotnet publish /t:PublishContainer, без Dockerfile. Пригодится, когда проект на .NET 10 надо упаковать в контейнер и запушить в реестр. CX Codex +1 2 800установок workflow-mastery Набор практик и готовых конфигураций для ускорения разработки на .NET в Claude Code. Помогает настроить параллельные сессии через git worktree, циклы верификации и лимиты контекста. CX Codex +1 2 800установок aspire Помогает настроить .NET Aspire для локального запуска сервисов, ресурсов и обнаружения сервисов. Нужен при работе с AppHost и общими настройками сервисов. CX Codex +1 2 800установок

Другие версии clean-architecture

Похожие

android-clean-architecture affaan-m Подсказывает агенту, как раскладывать Android- и KMP-проект по слоям: модули, зависимости, UseCase, репозитории, работа с Room, SQLDelight и Ktor. CX Codex +1 5 200установок dotnet-patterns affaan-m Набор архитектурных правил C# и ASP.NET Core для ИИ-ассистентов. Задаёт стандарты написания чистого кода, работы с DI, асинхронностью и обработкой ошибок. CX Codex +1 4 600установок migrate-dotnet10-to-dotnet11 dotnet Скилл переводит проекты и решения с .NET 10 на .NET 11. Он обновляет целевой фреймворк, пакеты и исправляет несовместимости C# 15 и EF Core 11. CX Codex +1 3 400установок migrate-dotnet9-to-dotnet10 dotnet Ведёт проект с net9.0 на net10.0: правит TargetFramework, чинит ошибки сборки и разбирает ломающие изменения .NET 10, C# 14, ASP.NET Core 10 и EF Core 10. CX Codex +1 3 400установок dotnet-fullstack-mentor официальный github Субагент-наставник по .NET: разбирает код и решения по уровням от junior до staff, опираясь на Clean Architecture, Aspire и практики C#. ★ 40 418звёзд репо csharp официальный github Правило задаёт Copilot стиль C#-кода: именование, nullable-типы, форматирование и работу с ASP.NET Core. Пригодится, если агент пишет по-разному в каждом файле. ★ 40 418звёзд репо

Рядом в теме «Бэкенд и API»

Всё по теме «Бэкенд и API» →

Вопросы о clean-architecture

Как установить clean-architecture в Claude?

Выполните npx skills add codewithmukesh/dotnet-claude-kit --skill clean-architecture -a claude-code. Файл скилла окажется по пути ~/.claude/skills/clean-architecture/SKILL.md.

Что делает clean-architecture?

Описывает четырёхслойную структуру .NET-проекта и даёт шаблоны: абстракция IAppDbContext, хендлеры команд и запросов, валидаторы, сущности с поведением. Скилл подключается, когда вы проектируете слои или обсуждаете инверсию зависимостей.

На каком стеке работает этот скилл?

Примеры построены на Mediator с генерацией исходников, FluentValidation и EF Core. Абстракция IAppDbContext выбрана вместо репозитория — по мнению автора, DbSet уже играет его роль.

Исходный текст

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

Смотрите также

Спонсоры проекта

Компании, которые помогают держать аналитику открытой