Comparison: Layered, Hexagonal, Onion, Clean and Vertical Slice
How the most used application architectures are alike and different, and how to choose between them.
#The common idea
Hexagonal (2005), Onion (2008) and Clean (2012) are variants of the same idea: the domain at the center and dependencies pointing inwards (Dependency Inversion). What changes is vocabulary and how much of the internal structure they prescribe. Layered, by contrast, usually does the opposite: the domain depends on the data layer.
#Comparison table
| Axis | Layered | Hexagonal | Onion | Clean | Vertical Slice |
|---|---|---|---|---|---|
| Author / year | Classic | Cockburn, 2005 | Palermo, 2008 | R. Martin, 2012 | Bogard, ~2018 |
| Metaphor | Stack of layers | Hexagon with ports | Onion | Concentric circles | Slices per feature |
| Dependency direction | Downwards (domain → data) | Towards the core | Towards the center | Towards the center | Inside the slice |
| Internal structure | Fixed layers | Just inside/outside | Model, domain, application | 4 named layers | Free per feature |
| Protagonist | The layer | The ports | The domain model | The use cases | The feature |
| Prescriptive | Little | Little | Medium | A lot | Little |
| Ceremony | Low | Medium | Medium | High | Low |
| Domain testability | Medium | High | High | High | Medium-high |
| Best for | CRUD, simple apps | Integrations and multiple clients | Rich domains (DDD) | Large teams with conventions | APIs with many independent features |
#Hexagonal vs Onion vs Clean
- Hexagonal emphasizes the symmetry between what comes in (driving) and what goes out (driven). It is the lightest and does not tell you how to arrange the core.
- Onion emphasizes the domain model and adds internal layers (domain and application services).
- Clean emphasizes use cases and defines the layers and how data crosses them.
- They can be combined: a common setup is an Onion/Clean core whose edge is organized as ports and adapters.
#Layered vs the others
The practical difference is who depends on whom. In classic Layered, the business references data access; in the others, the business defines the interface and infrastructure implements it. If your application is CRUD and the business logic is trivial, Layered with good practices is enough.
#Vertical Slice: another axis
Vertical Slice does not compete with Hexagonal: it organizes by feature instead of by layer. Inside each slice you can use a pragmatic approach (handler straight to EF for simple queries) and reserve a rich domain for the slices that have rules.
#Key questions to choose
| Question | If the answer is… | Lean towards |
|---|---|---|
| Are there complex business rules? | No, it's CRUD | Layered or Vertical Slice |
| Will the application live for years with many changes? | Yes | Hexagonal / Onion / Clean |
| Are there several entry points (API, jobs, CLI) or several external providers? | Yes | Hexagonal |
| Do you use DDD with a rich domain? | Yes | Onion or Clean |
| Is the team large and in need of explicit conventions? | Yes | Clean |
| Is adding a feature hard because you touch 5 folders? | Yes | Vertical Slice |
| Does the team have little experience with DI and abstractions? | Yes | Start with well-done Layered |
Rule: don't choose by name. Choose by problem. If the domain is simple, the simplest architecture that keeps the dependency rule healthy is the right one. You can evolve from Layered to Hexagonal when the pain shows up; the reverse path is rarer.
| Style | Main Pro | Main Con |
|---|---|---|
| Layered | Simplicity | The domain depends on infrastructure |
| Hexagonal | Light, isolates the edges | Doesn't guide the interior |
| Onion | Focus on the domain | Vocabulary similar to the others |
| Clean | Very explicit | Ceremony and boilerplate |
| Vertical Slice | Cohesion per feature | Duplication across slices |
#comparison #architecture