C
CIOPages
Back to Glossary

Architecture Patterns

Hexagonal Architecture (Ports and Adapters)

Hexagonal Architecture (also known as Ports and Adapters) is a software design pattern created by Alistair Cockburn that structures applications around the core business logic (domain), with defined ports (interfaces) that connect to external systems through adapters, ensuring the domain remains independent of infrastructure concerns like databases, UI frameworks, and external services.

Context for Technology Leaders

For CIOs, hexagonal architecture enables long-lived applications that can adapt to changing technology without rewriting business logic—essential for protecting technology investments. Enterprise architects advocate hexagonal architecture for domain-critical applications where business logic complexity justifies the structural investment.

Key Principles

  • 1Domain Independence: The core business logic has no dependencies on infrastructure, frameworks, or external systems, enabling it to be tested and evolved independently.
  • 2Ports as Contracts: Ports define the interfaces through which the application interacts with the outside world, establishing clear contracts between domain logic and infrastructure.
  • 3Adapters as Implementations: Adapters implement ports for specific technologies—a database adapter for PostgreSQL, an API adapter for REST—and can be swapped without changing the domain.
  • 4Testability: Domain logic can be tested with simple in-memory adapters, enabling fast, reliable unit tests without database or network dependencies.

Strategic Implications for CIOs

Enterprise architects should recommend hexagonal architecture for systems where business logic is complex, long-lived, and needs to survive multiple technology generations. The upfront structural investment pays off through reduced maintenance costs and technology migration effort.

Common Misconception

A common misconception is that hexagonal architecture is significantly more complex than layered architecture. While it requires more upfront design thought, the resulting code is often simpler to understand and maintain because dependencies are explicit and business logic is isolated from infrastructure concerns.

Related Terms