Overview
Layered Architecture stacks an application into horizontal layers, where each layer may only call the one directly beneath it. Hexagonal Architecture instead puts business logic at the center and connects it to the outside world through ports and adapters, so no top-to-bottom hierarchy exists at all. The distinction matters because it determines how easily you can swap infrastructure, test in isolation, and keep framework details from leaking into core logic.
Comparison Diagram
Comparison Table
| Aspect | Layered Architecture | Hexagonal Architecture |
|---|---|---|
| Structural organization | Horizontal layers (presentation, business, persistence); each layer only calls the one below it | Concentric layout with a domain core surrounded by ports and adapters; no top/bottom hierarchy |
| Dependency direction | Strictly downward: layer N depends only on layer N-1 | Always inward: adapters depend on the core, the core depends on nothing external |
| Entry and exit points | Requests enter at the presentation layer and exit at the database layer | Requests enter through any driving port and exit through any driven port |
| Business logic isolation | Business layer is often still coupled to persistence details that leak upward | Domain core is fully isolated behind port interfaces and unaware of any adapter |
| Swapping infrastructure | Replacing a database or UI framework often requires touching multiple layers | Swapping an adapter (e.g., DB for an in-memory store) requires no changes to the core |
| Testing strategy | Unit tests typically mock the layer directly beneath the one under test | Core logic is tested directly through ports; adapters are tested separately |
| Common pitfall | “Layered lasagna”: persistence concerns bleed upward into the business layer | Over-engineering ports and adapters for simple CRUD apps adds needless indirection |
| Best fit | Traditional CRUD apps with a straightforward request/response flow | Domain-heavy apps needing multiple interfaces (REST, CLI, events) or high testability |
Key Differences
- Layered enforces dependency in one direction (top-down) while hexagonal enforces dependency inward toward the domain core.
- Hexagonal defines explicit ports as boundaries; layered relies on looser, implicit layer contracts.
- Layered architecture is simpler to learn but prone to leaky abstractions between layers.
- Hexagonal architecture makes it trivial to swap infrastructure without touching business logic.
When to Use Each
Layered Architecture
- Simple CRUD Services: Straightforward request/response apps benefit from the familiar top-down structure without added indirection.
- Small Teams and Onboarding: New developers grasp layered architecture quickly since it maps directly to the request lifecycle.
- Rapid Prototyping: Fewer abstractions mean less boilerplate when speed matters more than long-term flexibility.
Hexagonal Architecture
- Multiple Delivery Mechanisms: Apps exposed via REST, CLI, and message queues can share one core without duplicating business logic.
- Heavy Domain Logic: Complex business rules stay isolated and testable independent of any framework or database.
- Frequent Infrastructure Changes: Swapping databases, message brokers, or third-party APIs only requires writing a new adapter.