Onion Architecture
Concentric layers with dependencies pointing inward toward the domain core.
Onion Architecture was articulated by Jeffrey Palermo in a series of 2008 blog posts, building on Hexagonal Architecture's core insight while presenting it as concentric layers — the domain model at the center, surrounded by domain services, then application services, then infrastructure and UI at the outer edges. The defining rule is the Dependency Rule: source code dependencies can point only inward (an outer layer can depend on an inner layer, but never the reverse), with the practical implementation using dependency inversion (interfaces defined in inner layers, implementations in outer layers). The concentric structure was Palermo's pedagogical contribution — making the inward dependency direction visually obvious. Onion sits between Hexagonal Architecture's ports-and-adapters framing and Clean Architecture's later synthesis, with the three patterns sharing the same fundamental dependency-inversion principle while differing in vocabulary, diagramming, and emphasis. Onion was particularly influential in the .NET community where Palermo was active.
Core components
- Concentric layers: Domain Model (innermost)
- Domain Services
- Application Services
- Infrastructure (and UI, Tests) (outermost)
- Dependency Rule (dependencies point only inward)
- Dependency inversion via interfaces in inner layers
- Domain at the center as application's reason for existing
- .NET community context
- Distinction from traditional N-tier (which has database at the bottom, leading to dependencies pointing toward infrastructure)
Primary use case
Application architecture, particularly in .NET and adjacent ecosystems; alternative diagramming for the same dependency-inversion principles as Hexagonal Architecture; teaching framework for layered architecture done right; common reference in enterprise application architecture discussions.
Common criticisms
- Substantial overlap with Hexagonal Architecture and Clean Architecture creates which-pattern-when confusion
- concentric-layers diagram is pedagogically clearer than Hexagonal but can suggest more rigid layering than Hexagonal's symmetric framing
- distinction between Domain Services and Application Services is genuine but often confusing in practice
- like Hexagonal, complexity overhead is unjustified for simple CRUD applications
- layer definitions and what belongs in each are somewhat arbitrary, creating team-by-team variations
- can be cargo-culted as four-or-five layers without the underlying dependency-rule discipline.
Lineage
- Parent of
- Clean Architecture
- Child of
- Hexagonal Architecture
- Siblings
- Hexagonal Architecture, Clean Architecture
- Derived from
- Hexagonal Architecture