Hexagonal Architecture – An Introduction
Despite its name, it really isn’t about hexagons.
Introduction to Hexagonal Architecture
I’m introducing a new blog series about Hexagonal Architecture (also known as Ports and Adapters). My previous blog posts have featured specific design patterns. This series is, in a way, continuing the design pattern theme. But instead of focusing upon specific design patterns, it will show how we can apply the design patterns that have already been presented. I will return to more design patterns once this Hexagonal Architecture series has been completed.
The internet is swarming with information about Hexagonal Architecture/Ports & Adapters (HexArch/P&A). I don’t want to replicate content that others have already provided. I’ll try to focus upon what I find interesting about HexArch/P&A that may not get as much coverage.
The series continues with:
- Hexagonal Architecture - Structure - This describes the structure of the Hexagonal Architecture design, and how it’s really a pattern or design patterns.
- Hexagonal Architecture - Why it works - This describes why I feel that the Hexagonal Architecture design works so well. It’s based upon dependency and knowledge management.
- Hexagonal Architecture - How it compares and contrasts with Clean Architecture - The two designs are mostly the same, but there are some differences worth pointing out.
- Hexagonal Architecture - Adapter Flexibility - We have quite a bit of flexibility with this design in the Adapter layer.
What is a Name?
I first heard of Hexagonal Architecture about 6 or 7 years ago. The name sounded funny. Later I heard that it’s also called Ports and Adapters. The same design has two names. Sigh. But that’s not all. The design basics are extremely similar to other designs, such as Clean Architecture (CleanArch) and Onion Architecture (OnionArch).
Don’t be overly concerned about the different names. It’s their shared core concepts that are important.
HexArch/P&A History
The HexArch design was conceived by Alistair Cockburn in the 1990s to decouple software components. He chose hexagons in his diagrams since he wanted to avoid rectangles. Rectangles tend to have preconceived notions in diagrams such as:
- They’re classes or objects
- They’re part of a layered architecture
- They have a fixed number of access points
He wanted to convey something different. His design focuses upon design boundary regions and their constraints.
The 6-sided hexagon has no architectural/design implications. Any number of sides would have sufficed. He chose the hexagon mainly because it was the easiest non-rectangular polygon to draw. Here’s 1-minute video where Cockburn talks about his choice of a hexagon.
Cockburn did want a shape with sides rather than a circle, which distinguishes HexArch from CleanArch in the diagrams. He wanted each side of a polygon to represent a facet as an access point. A polygon could have any number of facets or access points that it needed.
The polygon, whether a hexagon or other shape, isn’t an element in the implementation. It’s not a class, object, or other implementation concern. The hexagon is a design concept that defines a closed boundary and dependency and knowledge constraints associated with those boundaries. I’ll address the boundaries and constraints in future blog posts. See: Hexagonal Architecture - Why It Works.
Several years after his first designs, Cockburn was also learning more about design patterns, He realized that a facet is really a port, and he changed the name to Ports and Adapters. He still prefers this new name since it’s more descriptive of the pattern. But by then, many had been calling it Hexagonal Architecture and the original name still stuck. So now we have both names.
Design Patterns
The HexArch/P&A design is a pattern of design patterns, which only requires knowledge of the 7 Essential Design Patterns to understand.
I’m taking this detour into HexArch/P&A because it will reinforce those design patterns. I also think that HexArch/P&A is a fantastic way to design and implement a component without a huge investment. It can be applied on a large or small scale. It is not the kind of architecture/design choice that causes a major upheaval to the current code base. It can also be introduced into an existing design without having to restructure the entire code base.
Pluggable Design
Regardless of the name, HexArch/P&A, CleanArch, and OnionArch are all based upon a pluggable design.
The common core theme is that Business Domain implementation is sheltered in its own cocoon protected from external dependencies. I’ll spend more time in future blogs (See: Hexagonal Architecture) about what an external dependency may be, but to make it a bit more concrete here, one common example of an external dependency is the database.
The Business Domain implementation depends upon access points, which are the Ports in Cockburn’s nomenclature. In the implementation, these Ports will usually be interface contracts. Pluggable elements resolve the interface contract port references, which allows the Business Domain implementation to interact with external dependencies without depending upon those external dependencies nor having any knowledge of them.
Using the Gang of Four nomenclature, Ports will tend to be Strategies. The pluggable elements will be Adapters or Façades. Object resolution will occur via Dependency Injection.
Since the pluggable design isolates the Business Domain from external dependencies, the design allows us to delay dependency decisions. It allows us more flexibility to change external dependencies. I know that many projects will argue that they’re never going to change their external dependencies. Is it a case that they are never going to change to those external dependencies because they choose not to, or that they never can change them because they’ve become too tightly coupled to them?
And sometimes projects don’t have a choice. A dependency may be an external vendor who goes out of business. A project may be forced to change external dependencies even if that was never the plan.
Even if a project is 100% certain that an external dependency will never change, another reason to favor a pluggable design is for testing. A pluggable design accommodates test doubles more easily.
Boundaries and Constraints
I’m convinced that HexArch/P&A works because of boundaries and constraints it imposes. The constraint almost screams where implementation should reside and why it should reside there.
I will provide a separate blog about the boundaries and constraints.
That Hexagon Really Pulled the Room Together
HexArch/P&A pulls a lot of ideas together. It’s a structure which can be layered on top of other software engineering concepts, such as: Domain-Driven Design, Agile, Framework management, Form Factor management, Internationalization (I18n), Localization (L10n) and Accessibility (A11y).
And once we see how these different concepts relate to HexArch/P&A, we can see how they relate to each other. For example, Anti-Corruption Layer and Adapter are the same concept in two different contexts.
Summary
This has been a brief introduction to HexArch/P&A. Hopefully it has whetted your appetite for more. I’ll focus upon different aspects of HexArch/P&A in subsequent blogs posts.
If you want to learn more about HexArch/P&A in the interim, please do so with some of the references provided below.
References
Here are some free resources:
- Hexagonal Architecture on Wikipedia
- Alistair Cockburn’s Hexagonal Architcture page
- Alistair Cockburn’s Hexagonal Architecture reference page
- Hexagonal Architecture on Wiki C2
- Hexagonal Me - Great source of Hexagonal Architecture information
- Hexagonal architecture – is it for me? A no-nonsense overview
- HEXAGONAL ARCHITECTURE - WHAT IS IT? WHY SHOULD YOU USE IT?
- Hexagonal Architecture Design Pattern
- Hexagonal Architecture and Clean Architecture (with examples)
- HEXAGONAL ARCHITECTURE
- DDD, Hexagonal, Onion, Clean, CQRS, … How I put it all together
- Organizing Layers Using Hexagonal Architecture, DDD, and Spring
- Hexagonal Architecture: What Is It and How Does It Work?
- Architectural Approaches: Clean And Hexagonal Architecture
- A Color Coded Guide to Ports and Adapters
- Ports & Adapters (aka hexagonal) architecture explained
- Ports & Adapters Architecture
- Ports-And-Adapters / Hexagonal Architecture
- Ports-and-Adapters Architecture: The Pattern
- Hexagonal Architecture - Ports and Adapters
- The Clean Architecture - The first Clean Architecture blog by Bob Martin from 2012
- Screaming Architecture - Early Clean Architecture blog by Bob Martin from 2011, which focuses upon obvious architectures
- Summary of book “Clean Architecture” by Robert C. Martin
- Clean architecture for the rest of us
- Use Case Diagrams Wikipedia - Use Cases are referenced quite a bit in Clean Architecture and sometimes in Hexagonal Architecture
- and for more Google Hexagonal Architecture Ports and Adapters Clean Architecture Onion Architecture
Here are some free online video resources:
- “Hexagonal Architecture & Legacy Code” by Jim Humelsine
- Alistair in the “Hexagone” 1/3
- Alistair in the “Hexagone” 2/3
- Alistair in the “Hexagone” 3/3
- Hexagonal Architecture: What You Need To Know - Simple Explanation
- Hexagonal Architecture and Clean Architecture (with examples)
- Hexagonal Architecture (Ports and Adapters) with Alistair Cockburn
- Structure your microservice using a hexagonal architecture by Fredrik Lindgren
- The Principles of Clean Architecture by Uncle Bob Martin
- ITkonekt 2019 Robert C. Martin (Uncle Bob), Clean Architecture and Design
- Robert C Martin - Clean Architecture and Design
- More Testable Code with the Hexagonal Architecture
Here are some resources that can be purchased or are included in a subscription service:
- Clean Architecture by Bob Martin (Amazon and O’Reilly)
- Get Your Hands Dirty on Clean Architecture by Tom Hombergs (Amazon and O’Reilly)
- Architecture, Use Cases and High Level Design, Video by Bob Martin (O’Reilly)