Hexagonal Architecture
Also known as: Ports and Adapters
Cockburn's design isolating business logic from delivery and infrastructure concerns.
Hexagonal Architecture, articulated by Alistair Cockburn in his 2005 essay 'Hexagonal Architecture' (also known as Ports and Adapters), structures applications so that core business logic at the center is isolated from external concerns (UI, databases, external services) at the edges, with the connection mediated by ports (interfaces defined by the core) and adapters (implementations connecting external systems to those ports). The hexagonal shape in Cockburn's diagrams is symbolic — it suggests multiple equal sides for different connections, in contrast to layered diagrams that imply UI-on-top hierarchy. The architecture's central commitment is that the application's behavior should be testable in isolation from any specific UI, database, or external service, with adapters substitutable in tests. Hexagonal is closely related to Onion Architecture (Palermo 2008) and Clean Architecture (Martin 2012), all of which share the core insight that dependencies should point inward toward the domain core rather than outward toward infrastructure. Cockburn's original framing emphasized the practical testability benefits more than philosophical layering.
Core components
- Core business logic at the center
- Ports (interfaces defined by the core for what it needs from outside)
- Adapters (implementations connecting external systems to ports)
- Symmetric structure (UI, database, external services all on equal footing)
- Driving adapters (initiate flow into the core: UI, API) vs Driven adapters (called by the core: database, external services)
- Substitutability in tests
- Dependency inversion at port boundaries
Primary use case
Application architecture where business logic complexity warrants isolation from infrastructure concerns; foundation for testable application design; basis for microservices internal structure; combination with DDD's tactical patterns; teaching tool for dependency-inversion thinking.
Common criticisms
- Substantial complexity overhead for simple CRUD applications where business logic is thin
- learning curve is steep, with many adopters cargo-culting the structure without the underlying testability discipline
- risk of over-abstraction creating layers and indirection without value
- the hexagon shape and 'ports and adapters' vocabulary can become more confusing than the dependency-inversion principle they encode
- substantial overlap with Onion and Clean Architecture creates which-pattern-when confusion
- adapter-per-external-thing structure can produce excessive infrastructure code
- some implementations adopt Hexagonal but violate the dependency rule by leaking infrastructure types into the core.
Lineage
- Parent of
- Onion Architecture, Clean Architecture
- Siblings
- Onion Architecture, Clean Architecture, Domain-Driven Design