Hexagonal Architecture
Architectural pattern isolating business logic from the outside world through ports and adapters, facilitating testing and technology changes.
What it is
Hexagonal architecture (also called Ports & Adapters) organizes code in layers where business logic is at the center, completely isolated from technical details like databases, APIs, or frameworks.
Structure
[HTTP Adapter] → [Input Port] → [Domain] → [Output Port] → [DB Adapter]
- Domain: pure business logic, no external dependencies
- Ports: interfaces defining how the domain interacts with the outside
- Adapters: concrete implementations of ports
Benefits
- Domain testing without infrastructure
- Change database without touching business logic
- Multiple interfaces (HTTP, CLI, events) for the same logic
- Clear separation of responsibilities
Relationship with other architectures
| Architecture | Author | Layers | Key difference |
|---|---|---|---|
| Hexagonal (Ports & Adapters) | Alistair Cockburn, 2005 | Domain → Ports → Adapters | Focus on ports as contracts |
| Clean Architecture | Robert Martin, 2012 | Entities → Use Cases → Adapters → Frameworks | Concentric layers, dependencies point inward |
| Onion Architecture | Jeffrey Palermo, 2008 | Domain Model → Domain Services → Application → Infrastructure | Similar to Clean, emphasis on domain model |
All three share the fundamental principle: dependencies point inward, protecting business logic from infrastructure details.
Why it matters
Hexagonal architecture protects business logic from infrastructure details. When the database, web framework, or cloud provider changes, only the adapters are modified — the domain remains intact. It is the investment in long-term maintainability.
References
- Hexagonal Architecture — Alistair Cockburn, 2005.
- Ready for Changes with Hexagonal Architecture — Netflix Tech Blog, 2020. Netflix case study.
- DDD, Hexagonal, Onion, Clean, CQRS — Herberto Graça, 2017. Architecture comparison.
Related content
- Domain-Driven Design
Software design approach centering development on the business domain, using a ubiquitous language shared between developers and domain experts.
- Microservices
Architectural style structuring an application as a collection of small, independent, deployable services, each with its own business logic and data.
- Strangler Fig Pattern
Incremental migration strategy that gradually replaces a legacy system with new components, progressively routing traffic until the old system can be retired.