Vertical Slice Architecture

The idea in one minute

Vertical Slice Architecture organises code around individual requests: “validate a configuration”, “apply a configuration”, “register a device”. Everything one request needs sits together: its endpoint, request and response types, validation, handler and the data access only it uses. Jimmy Bogard summarises the principle as “minimize coupling between slices, and maximize coupling in a slice.”^[1]

The argument is about where change happens. A new feature in a layered design touches a controller, a service, a repository and their interfaces, each in a different project. In a sliced design the same feature adds one folder. Bogard calls this coupling “along the axis of change”.^[1]

Validate configurationApply configurationRegister deviceExport reportEndpointRequest + validationHandler / logicData accessSharedDomain model: entities and rules used by many slices

One vertical slice: everything for one requestLayered designs group these by row instead

When it fits

These criteria follow Jovanović’s 2026 assessment,^[9] and Bogard’s own precondition: the approach assumes the team understands code smells and refactoring.^[1]

How a slice is built

• One folder (or one file) per request. Bogard’s reference app keeps the query, validator, command, mapping and handlers of one page in a single file.^[5]
• Each slice chooses its own approach. Start with a simple transaction script; refactor to domain objects when smells appear. New features only add code, they do not change shared code.^[1]
• Commands and queries fall out naturally, which is how CQRS arrived “out of the gate” in Bogard’s own move away from onion architecture.^[1]
• A mediator is optional. MediatR is common in .NET samples, but became commercial in 2025 for companies above a revenue threshold;^[6] plain handlers or endpoint libraries (REPR: request, endpoint, response) work just as well.^[12]

Where shared logic goes

Jovanović separates three kinds of sharing:^[8]

His heuristics: one duplicate is fine, three should raise an eyebrow, and duplication is cheaper than the wrong abstraction.^[8]

Worked example: a configuration tool

An illustrative layout. Slices own requests; the domain model holds rules many slices need.

src/ConfigTool.Api/
  Features/
    Configurations/
      ValidateConfiguration/
        Request.cs     // record: DeviceId, Payload
        Validator.cs   // shape and schema checks
        Handler.cs     // loads the device profile, asks the domain
        Endpoint.cs    // POST /devices/{id}/config:validate
      ApplyConfiguration/ ...
      Shared/          // only for configuration slices
    Devices/
      RegisterDevice/ ...
  Domain/              // DeviceProfile, ConfigRule: shared invariants
  Infrastructure/      // DbContext, device protocol adapters
tests/
  ConfigTool.IntegrationTests/Features/Configurations/
  ConfigTool.ArchitectureTests/

public static class ValidateConfiguration
{
    public sealed record Request(DeviceId DeviceId, ConfigPayload Payload);

    public sealed class Handler(ConfigDb db)
    {
        public async Task<ValidationReport> Handle(Request req, CancellationToken ct)
        {
            var profile = await db.DeviceProfiles.SingleAsync(p => p.Id == req.DeviceId, ct);
            return profile.Validate(req.Payload);   // the rule lives on the domain object
        }
    }
}

Where it is used in practice

• Bogard’s reference application (Contoso University) and his talks since NDC Oslo 2015.^[2][5]
• Ardalis’ Clean Architecture template ships a minimal, single-project variant organised as vertical slices next to the classic four-project layout.^[12]
• SSW publishes it as a consulting rule (“features do not reference each other”)^[13] and ships a .NET template with architecture tests built in.^[14]
• Combined with Clean Architecture: slices organise behaviour while Clean Architecture controls dependency direction.^[10] Bogard’s own session covers mixing slices with layers, CQRS and DDD.^[3]

Gains and costs

How it goes wrong

1. The Common junk drawer. A shared Common or Utils project collects everything and brings back the coupling slices were meant to remove.^[8]
2. Slices calling slices. Use the domain, events or a small public facade instead of reaching into another slice’s handler.^[8]
3. Anaemic slices. Every rule written inline in handlers, copied three times, never pushed into the domain.
4. Shared DTOs. One request type reused across slices couples them through the back door.
5. Abstracting too early. Generic base handlers and repositories before the third duplicate.
6. Huge slices. A use case that grows until it does too much; split it like any other oversized class.^[9]

Guardrails and testing

Bogard’s 2026 talk is explicit that slices remove some structural guardrails and that mechanical ones must replace team discipline: architecture tests, conventions kept in the repository, and a reference slice to copy.^[4]

• Architecture tests (for example NetArchTest) enforce that features do not reference each other and that the domain does not depend on infrastructure.^[15]
• Conventions in the repo: a short guide and one exemplary slice new features copy.
• Test by feature, not by layer: name tests after slices, drive them through the real HTTP boundary against a real database in a container, and unit-test only validators and complex domain logic.^[11] Bogard’s reference app uses integration tests only, with a fixture that sends requests through the same pipeline as production.^[5]

Origins

• 2015: Bogard’s talk “SOLID Architecture: Slices not Layers” at NDC Oslo, after moving away from onion architecture toward CQRS.^[2]
• 2018: the blog post “Vertical Slice Architecture” that gave the style its name and principle.^[1]
• 2021 onward: practitioners such as Derek Comartin frame it as a question of coupling and dependencies: things that change together belong together.^[7]
• 2026: Bogard positions slices as guardrails for AI-assisted development, paired with architecture tests and repository conventions.^[4]