Vertical Slice Architecture (VSA) for .NET applications — one of several supported architectures in dotnet-claude-kit. Covers feature folders, endpoint grouping, and handler patterns for Mediator, Wolverine, and raw handler classes. Load this skill when the architecture-advisor recommends VSA, when

Vertical Slice Architecture (VSA) Core Principles 1. Organize by feature, not by layer — Each feature is a self contained vertical slice containing its endpoint, handler, request/response types, and validation. No more jumping between Controllers/, Services/, Repositories/ folders. 2. Minimize cross feature coupling — Features should not reference each other directly. Shared concerns go in a Common/ or Shared/ directory. 3. One file per feature is fine — A simple CRUD endpoint doesn't need 5 files spread across layers. Start with everything in one file, extract only when complexity demands it. 4. The handler is the unit of work — Each handler does one thing. No god services with 20 methods. Patterns Feature Folder Structure Pattern A: Mediator Handlers (Recommended Default) Source generated mediator — MIT licensed, no reflection, Native AOT compatible. Uses IRequest<T / IRequestHandler<TRequest, TResponse with pipeline behaviors. Near identical API to MediatR but faster and free. Package: Mediator.Abstractions + Mediator.SourceGenerator . Pattern B: Wolverine Handlers Convention based — no interfaces to implement. Wolverine discovers handlers by method signature. Pattern C: Raw Handler Classes (No Library) Direct handler classes with no external dependency. Good for small projects or teams that want full control. Adding Module Boundaries (Optional) For larger applications that grow beyond a single project, introduce module boundaries. Each module is a separate class library with its own features and DbContext. Modules communicate via: Integration events (preferred) — async, decoupled via Wolverine or MassTransit Shared contracts — a MyApp.Contracts project with DTOs/interfaces (use sparingly) Shared Concerns Cross cutting concerns live outside feature folders: Anti patterns Don't Create Layered Abstractions Within a Slice Don't Cross reference Features Directly Don't Put Everything in One God Feature File Decision Guide Scenario Recommendation New project (default) Pattern A — Mediator (source generated, MIT, fast) Need mediator + messaging in one lib Pattern B — Wolverine (also handles events/queues) Want full control, no dependencies Pattern C — Raw handler classes Existing MediatR codebase with license Keep MediatR if licensed; otherwise migrate to Mediator (near identical API) Monolith growing complex Add module boundaries, keep VSA within each module Simple CRUD feature Single file: request + handler + endpoint Complex feature (saga, events) Multiple files in feature folder, still colocated Sharing logic between features Extract to Common/ — not to another feature

vertical-slice