Hexagonal Architecture

Definition

Hexagonal architecture — also known as Ports and Adapters — is a software architecture pattern in which the core application logic sits at the center, untouched by the specifics of any database, messaging system, user interface, or third-party integration. Every interaction with the outside world passes through a 'port,' a defined interface, and is handled by an 'adapter,' a piece of code that translates between the port and a specific external technology. The hexagon shape is symbolic, not literal: it represents that the core can have any number of ports on any side, rather than the traditional layered picture of UI on top and database on bottom. For business and enterprise architects, hexagonal architecture matters less as a coding technique and more as a structural discipline that determines how cleanly a system's technical implementation can track the boundaries of a business capability. When application teams honor the pattern, the core logic — pricing rules, claims adjudication, underwriting decisions — can be modeled, tested, and evolved independently of whichever channel, database, or vendor happens to be delivering data to it today. It is important to distinguish hexagonal architecture from business architecture artifacts themselves. A capability map or value stream defines what the business does and where its boundaries lie; hexagonal architecture is one way solution and technical architects implement those boundaries in code so the technology stays aligned to the business model rather than fossilizing around a single vendor or integration choice. It does not replace capability-based planning, domain-driven design, or service design — it operationalizes them at the code level.

Origin & Context

The term was coined by Alistair Cockburn around 2005 as an alternative to the traditional layered (n-tier) architecture, aiming to solve the problem of business logic becoming entangled with UI and database code. It emerged alongside — and is closely related to — domain-driven design and later 'clean architecture' and 'onion architecture,' all of which share the same core idea of isolating business rules from technical infrastructure. Within enterprise architecture practice, it is typically discussed under application and solution architecture domains, at the point where the capability model meets actual system design.

Why It Matters

Enterprise architects and CIOs care about hexagonal architecture because it directly affects how quickly technology can adapt when the business changes — a new payment provider, a core banking replacement, a new regulatory reporting requirement, or an acquired company's systems. When core logic is properly decoupled, these changes touch adapters, not the business rules themselves, which materially reduces the cost and risk of technology change and shortens M&A integration timelines. Business architects care because it gives them a credible technical partner for keeping the capability model and the system landscape in sync — a hexagon's ports map naturally onto capability boundaries. Poorly bounded architectures, by contrast, are the reason legacy modernization programs stall: the business logic is so entangled with a specific database or UI that no one can safely touch it.

Common Misconceptions

Myth: Hexagonal architecture is a business architecture framework, similar to a capability model or operating model.

Reality: It is a software architecture pattern applied by solution and technical architects, not a business architecture deliverable. Business architects define the capability boundaries and business rules; hexagonal architecture is one method engineering teams use to implement those boundaries cleanly in code so the system stays aligned to the business model over time.

Myth: The 'hexagon' means the architecture must have exactly six ports or sides.

Reality: The hexagon is a visual metaphor chosen simply because it has more than the two sides a layered diagram implies. A real implementation might have two ports or a dozen — one for the UI, one for a database, one for a message queue, one for each external partner integration — the number is dictated by actual integration needs, not the shape of the diagram.

Myth: Hexagonal architecture is an alternative to microservices, and organizations must choose one or the other.

Reality: They operate at different levels and are commonly used together. Microservices is a decision about how to decompose a system into independently deployable services; hexagonal architecture is a decision about how to structure the inside of any one of those services so its core logic stays independent of its technical dependencies.

Practical Example

A mid-sized insurer was replacing its aging policy administration system while keeping its claims adjudication logic intact. The business architecture team had already defined a Claims Processing capability with clear inputs, outputs, and business rules as part of the enterprise capability map. The solution architect used hexagonal architecture to isolate the claims adjudication core, exposing ports for policy data, payment execution, and customer notifications. Each port had its own adapter: one for the legacy policy admin system during transition, another for the new cloud-based platform once migrated, and a third for a new digital claims portal. Because the core adjudication logic never referenced any of these systems directly, the team was able to cut over from the old policy admin system to the new one, and later onboard a new payment processor, without touching the adjudication rules at all. The business architecture governance board used the capability boundaries to validate that the technical port structure matched the intended business boundaries before implementation began.

Industry Applications

Financial Services

Isolating core ledger and transaction-posting logic from channel-specific adapters (branch, mobile, ATM, partner APIs) during core banking modernization, so channels can be added or replaced without touching the ledger's business rules.

Insurance

Decoupling underwriting and claims adjudication logic from policy administration and third-party data providers, allowing insurers to swap rating engines, reinsurance systems, or claims portals independently of the core decision logic.

Healthcare

Separating clinical decision-support logic from electronic health record integrations, using ports aligned to interoperability standards like FHIR so the same core logic can serve multiple EHR vendors and care settings.

Related Terms

• Domain-Driven Design: A complementary software design approach that hexagonal architecture is frequently paired with to define the core logic's boundaries
• Application Architecture: The broader enterprise architecture domain in which hexagonal architecture is one recognized structural pattern