clean-architecture
Skill229 starsChanged 3 months agoApache-2.0View on GitHub
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.
We split this skill into the rules it gives an agent
1 rule. 0 are common, 0 are distinctive, and 1 is very specific to this project.
0
Common
Most of the 23 edited versions we read keep these.
0
Distinctive
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 227
Every endpoint group implements IEndpointGroup and is auto-discovered via app.MapEndpoints().
“Common” is measured: kept by at least 6 in 10 of the 23 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Clean Architecture
Core Principles
- 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.
- 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.
- 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.
- 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.
- 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.csDbContext Abstraction (Preferred Over Repository)
Define a minimal interface in Application; implement in Infrastructure:
// 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)
// 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)
// 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
// 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.
// 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
// 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
// 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
// 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
// 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
// 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 casesDecision 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/ |
Other versions25 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 25
- ciembor/agent-rules-books★ 2.8ksame name
- wondelai/skills★ 2.2ksame name
- Mindrally/skills★ 275same name
- GabrielMartinMoran/mind★ 193same name
- tokenaissance/clean-architecture★ 17same name
- G1Joshi/Agent-Skills★ 15same name
- korallis/skills-collection★ 14same name
- zdanovichnick/dotnet-pilot★ 5same name
- kayaman/skills★ 3same name
- Adhamxon/claude-code-skills★ 2same name
15 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
Used alongsideProjects with it also use domain-driven-design, clean-code and 3 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
jarrodmedranoSkilldomain-driven-design
This skill should be used whenever domain modeling is taking place. It provides specialized guidance for type-driven and data-driven design based on Rich Hickey and Scott Wlaschin's principles. The skill helps contextualize current modeling within the existing domain model, identifies inconsistencies, builds ubiquitous language, and creates visualizations (Mermaid, Graphviz/DOT, ASCII diagrams) to communicate domain concepts clearly. Use this skill when designing types, modeling business domains, refactoring domain logic, or ensuring domain consistency across a codebase.
Also in 4 projects that use this
xenitV1Skillclean-code
Pragmatic coding standards - concise, direct, no over-engineering, no unnecessary comments
Also in 6 projects that use this
ffsshhttiikkSkilldesign-patterns
Practical application and coding skills for Design Patterns
Also in 3 projects that use this
SentrySkillsecurity-review
Finds exploitable application security vulnerabilities in code changes. Use for Warden security scans, appsec review, OWASP-style checks, authentication or authorization bugs, injection, XSS, SSRF, path traversal, secrets, unsafe crypto, webhook verification, open redirects, or sensitive data exposure.
Also in 3 projects that use this
GoogleSkillimprove-codebase-architecture
Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.
Also in 3 projects that use this
In this repository96 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- .github/copilot-instructions.mdCopilot instructions
- 80-20-reviewSkill
- api-versioningSkill
- architecture-advisorSkill
- aspireSkill
- authenticationSkill
- autonomous-loopsSkill
- cachingSkill
- ci-cdSkill
- code-review-workflowSkill
- configurationSkill
- container-publishSkill
- context-disciplineSkill
- convention-learnerSkill
- dddSkill
- dependency-injectionSkill
- de-sloppifySkill
- dockerSkill
- ef-coreSkill
- error-handlingSkill
- health-checkSkill
- httpclient-factorySkill
- instinct-systemSkill
- learning-logSkill
- loggingSkill
- messagingSkill
- migration-workflowSkill
- minimal-apiSkill
- model-selectionSkill
- modern-csharpSkill
- openapiSkill
- opentelemetrySkill
- project-setupSkill
- project-structureSkill
- resilienceSkill
- scaffoldingSkill
- scalarSkill
- security-scanSkill
- self-correction-loopSkill
- serilogSkill
- session-managementSkill
- split-memorySkill
- testingSkill
- verification-loopSkill
- vertical-sliceSkill
- workflow-masterySkill
- wrap-up-ritualSkill
- 80-20-reviewSkill
- api-versioningSkill
- architecture-advisorSkill
- aspireSkill
- authenticationSkill
- autonomous-loopsSkill
- cachingSkill
- ci-cdSkill
- clean-architectureSkill
- code-review-workflowSkill
- configurationSkill
- The first 60 shown.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

