Vertical Slice Architecture: Build Features, Not Layers

Vertical Slice Architecture: Build Features, Not Layers

04 Aug 2026

When most .NET teams scale their applications, they reach for the familiar three-layer architecture: Controllers, Services, and Repositories. It works at first, but eventually a single feature change ripples through five different files across three different projects. Enter Vertical Slice Architecture, where every feature is a self-contained module with its own business logic, data access, API endpoints, and UI components.

Brand Website V3 takes this further. Each domain module (Blog, Reviews, Shop, etc.) is organized as a vertical slice with no cross-references between its internal layers. Modules talk to each other only through the host project. This means you can literally copy-paste an entire module from one project into another and it just works.

Blog/
  Blog._Shared/           // DTOs, routes, permissions (shared front+back)
  Blog._Shared.Spa/       // Blazor components, HttpClient, State
  Blog.Api/               // Minimal API endpoints (class library)
  Blog.Database/          // EF Core DbContext, entities, migrations
  Blog.Features/          // CQRS handlers, validators

This structure is not about throwing away separation of concerns. It is about making each module self-contained. The Blog module still has clear boundaries between its API, features, and database layers. The difference is that those boundaries exist within the module, not stretched across a shared project tree where every module fights for space.


Why It Works

  • Each module is independently deployable and testable. You can test the Blog module without pulling in Reviews or Shop dependencies.
// Only host projects reference module libraries
services.AddBlogModule(configuration);
  • Merge conflicts drop dramatically. Two developers working on different modules never touch the same project files.
// Blog and Reviews have completely separate .csproj files
// No shared Projects/ or Features/ folder to fight over
  • Clear ownership boundaries. The Blog module owns its database context, its entities, its endpoints, and its UI. Nobody else pokes at it.
// Blog.Database only exposes what Blog.Features needs
public interface IBlogDbContext : ISaveChangesAsync

The Host Project Orchestrates Everything

Only the host projects (Brand.Api, Brand.PrerenderServer) know about all the modules. They wire everything together at startup, but the modules themselves remain blissfully ignorant of each other. This is the key insight: the host is the composition root, not a shared core library.

// Brand.Api/Program.cs
builder.Services.AddBlogModule(builder.Configuration);
builder.Services.AddReviewsModule(builder.Configuration);
builder.Services.AddShopModule(builder.Configuration);

Each module registers its own services, its own database context, and its own endpoints. The host just calls the registration methods.


Ready to build your .NET application the right way? Brand Website V3 implements Vertical Slice Architecture across 11 domain modules, all built on .NET 10 with a modular monolith approach. See the full implementation at kiss-code.com.


Join the community

I continuously build, learn and experiment with innovative technology. Allow me to share what I learn, with you.

Newsletter

Allow me to share what I learn, with you.

Share

Support

An error has occurred. 🗙