Design Pattern Evangelist Blog

Smart pointers about software design

Hexagonal Architecture – An Introduction

Despite its name, it really isn’t about hexagons.

Building with 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:

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:

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.

Cocoons

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 those dependencies 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. See: Hexagonal Architecture - Why It Works.

That Hexagon Really Pulled the Room Together

The Dude

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:

Here are some free online video resources:

Here are some resources that can be purchased or are included in a subscription service:

Comments

Previous: Dependency Injection

Next: Hexagonal Architecture – The Structure

Home: Design Pattern Evangelist Blog