# Vertical Slice Architecture vs Clean Architecture

> Clean Architecture manages complexity through layer discipline. Vertical Slice Architecture manages it through feature isolation. Teams treat this as a religious war, but it is a fit question: rich shared domain logic points one way, features with wildly different complexity point the other. Here is how the two compare, and the hybrid most real projects land on.

Published: 2026-08-13. Author: Milan Jovanović.

Canonical: https://milanjovanovic.tech/blog/vertical-slice-vs-clean-architecture

Neither architecture is better universally, and the choice is a fit question, not a religious war.
**Clean Architecture** manages complexity through layer discipline, and it wins when features share a rich domain model.
**Vertical Slice Architecture** manages complexity through feature isolation, and it wins when features vary wildly in complexity.
Here is how they compare, when to pick which, and the hybrid that many real projects land on.

## Two Different Philosophies

[**Clean Architecture**](https://milanjovanovic.tech/blog/clean-architecture-and-the-benefits-of-structured-software-design) organizes code by **technical layer** - Domain, Application, Infrastructure, Presentation. Each layer has clear responsibilities, and dependencies point inward.

[**Vertical Slice Architecture**](https://milanjovanovic.tech/blog/vertical-slice-architecture) organizes code by **feature** - each feature is a self-contained slice that cuts through all layers from UI to database. You don't share code between slices unless it's a genuine cross-cutting concern.

Both are valid. But they optimize for different things.

![Clean Architecture groups code into Presentation, Application, Domain, and Infrastructure layers, while Vertical Slice Architecture groups code into self-contained feature slices](https://milanjovanovic.tech/blogs/articles/vertical-slice-vs-clean-architecture/clean-vs-vsa.png)

## Clean Architecture in Brief

Clean Architecture separates your solution into concentric layers:

```
Presentation → Application → Domain ← Infrastructure
```

The dependency rule: inner layers define abstractions, outer layers implement them.

A typical project structure:

```
MyApp.Domain/         ← Entities, Value Objects, Interfaces
MyApp.Application/    ← Use Cases, DTOs, Validators
MyApp.Infrastructure/ ← EF Core, External APIs
MyApp.Api/            ← Controllers, Endpoints
```

Adding a new feature means touching **multiple projects**: define the entity in Domain, add a command/handler in Application, configure persistence in Infrastructure, add an endpoint in Presentation.

## Vertical Slice Architecture in Brief

Vertical Slice Architecture groups everything for a feature together:

```
Features/
  PlaceOrder/
    PlaceOrderEndpoint.cs
    PlaceOrderCommand.cs
    PlaceOrderHandler.cs
    PlaceOrderValidator.cs
  GetOrderById/
    GetOrderByIdEndpoint.cs
    GetOrderByIdQuery.cs
    GetOrderByIdHandler.cs
    OrderResponse.cs
```

Adding a new feature means creating a **new folder** with all the code for that feature. You don't modify existing features.

## Key Differences

### Coupling Direction

**Clean Architecture** couples by _layer_. All repositories live together. All entities live together. Changing how repositories work could affect many features.

**Vertical Slices** couple by _feature_. Each feature is independent. Changing the PlaceOrder feature doesn't affect GetOrderById.

### Code Reuse

**Clean Architecture** encourages code reuse across features. A shared `OrderRepository` serves every use case that needs orders.

**Vertical Slices** minimize shared code. Each feature can query the database differently. PlaceOrder might use a repository; GetOrderById might use raw Dapper.

### Consistency

**Clean Architecture** enforces consistency. Every feature follows the same patterns - same handler structure, same validation approach, same repository layer.

**Vertical Slices** allow variation. Simple CRUD features can be simple. Complex features can use rich domain models. Each slice uses what it needs.

### Indirection

**Clean Architecture** adds layers of indirection. To trace a request from endpoint to database, you pass through multiple abstractions: endpoint → handler → repository → DbContext.

**Vertical Slices** minimize indirection. A simple query handler might go straight to the database with no intermediate abstractions.

## Side-by-Side Comparison

Here's how the two approaches stack up, dimension by dimension:

|  | Clean Architecture | Vertical Slice Architecture |
| --- | --- | --- |
| Organization | By technical layer | By feature |
| Coupling | Within layers | Within features |
| Code reuse | High, through shared services and repositories | Intentionally low |
| Consistency | Enforced by uniform patterns | Each slice picks its own abstraction level |
| New feature effort | Touches multiple projects | One new folder |
| Learning curve | Moderate to high | Low |
| Best for | Complex domain logic | Features with varied complexity |
| Main risk | Over-engineering simple features | Duplication between features |

## When to Choose Clean Architecture

**Choose Clean Architecture when:**

1. **Your domain is complex.** If you have rich business rules, invariants, and domain events, Clean Architecture gives you the structure to manage that complexity.

2. **Multiple features share domain logic.** If your Order entity is used by PlaceOrder, CancelOrder, RefundOrder, and ShipOrder - sharing it through a Domain layer makes sense.

3. **You want strict architectural boundaries.** Clean Architecture's layers can be enforced with [**architecture tests**](https://milanjovanovic.tech/blog/enforcing-software-architecture-with-architecture-tests), giving you confidence that infrastructure doesn't leak into your domain.

4. **Your team is large and values uniformity.** One enforced pattern for every use case keeps dozens of developers producing code that looks the same, which pays off in reviews and onboarding.

5. **The project is long-lived.** The upfront investment in structure pays off over years as the codebase grows.

## When to Choose Vertical Slice Architecture

**Choose Vertical Slices when:**

1. **Features have different complexity.** Some endpoints are simple CRUD, others have complex workflows. Vertical slices let each feature use the appropriate level of abstraction.

2. **You want fast feature delivery.** New features are self-contained. You don't need to understand the entire repository layer to add a new query.

3. **Your team is small.** Less infrastructure to maintain. Fewer abstractions to navigate.

4. **You're building a CRUD-heavy API.** If most features are thin wrappers around database operations, layers add overhead without value.

5. **You want to minimize coupling.** Features that don't share code can be modified and tested in isolation, without touching the rest of the system.

## Can You Combine Them?

Yes. And many teams do.

A common approach: use **Vertical Slices for feature organization** inside a **Clean Architecture solution structure**.

```
MyApp.Application/
  Features/
    Orders/
      PlaceOrder/
        PlaceOrderCommand.cs
        PlaceOrderCommandHandler.cs
      GetOrderById/
        GetOrderByIdQuery.cs
        GetOrderByIdQueryHandler.cs
    Customers/
      RegisterCustomer/
        RegisterCustomerCommand.cs
        RegisterCustomerCommandHandler.cs
```

You get:

- Feature-based organization (vertical slices)
- Layer boundaries enforced at the project level (Clean Architecture)
- Shared domain model for complex business rules
- Independent use cases that don't affect each other

This hybrid approach is what I use in my [Pragmatic Clean Architecture course](https://milanjovanovic.tech/pragmatic-clean-architecture). It gives you the best of both worlds.

## Common Mistakes

**1. Using Clean Architecture for everything.** A simple API with five CRUD endpoints doesn't need four projects and a dozen abstractions.

**2. Duplicating everything in Vertical Slices.** If three features need the same validation logic, extract it. "Minimize code sharing" doesn't mean "never share code."

**3. Choosing based on popularity, not fit.** Clean Architecture is more popular in .NET. That doesn't make it the right choice for every project.

**4. Thinking it's permanent.** You can start with Vertical Slices and introduce layer boundaries as complexity grows. Architecture should evolve with your project. If you're unsure where your project falls, I've written about [**when to choose Vertical Slice Architecture**](https://milanjovanovic.tech/blog/when-to-choose-vertical-slice-architecture) in more detail.

## Summary

Clean Architecture and Vertical Slice Architecture solve different problems:

- **Clean Architecture** manages complexity through **layer discipline**
- **Vertical Slices** manage complexity through **feature isolation**

For complex domains with shared business rules → Clean Architecture.
For varied features with different complexity levels → Vertical Slices.
For most real projects → a pragmatic combination of both.

Thanks for reading, and stay awesome!

---

## Frequently asked questions

### Is Vertical Slice Architecture better than Clean Architecture?

Neither is better universally. Clean Architecture manages complexity through layer discipline and shines with rich domain logic. Vertical slices manage complexity through feature isolation and shine when features vary in complexity. Many real projects combine both.

### Can you use Vertical Slice Architecture with Clean Architecture?

Yes. A common hybrid keeps Clean Architecture project boundaries (Domain, Application, Infrastructure, API) and organizes the Application layer into feature folders, so each use case is a self-contained slice.

### Does Vertical Slice Architecture cause code duplication?

Some, intentionally. Slices avoid premature abstraction, which means similar code can appear in two features. When duplication represents a genuine shared rule, you extract it to the domain model or a shared service.

### Which architecture is easier for small teams?

Vertical Slice Architecture, usually. There is less infrastructure to maintain, fewer abstractions to navigate, and a new feature is one new folder instead of changes across four projects.