Hexagonal Architecture’s Common Misconceptions
Introduction
The hexagonal architecture is simple, elegant, and beautiful. It’s also a well-defined architecture. Alistair Cockburn published at least two articles describing it. However, even in 2020, we still read on some famous blog posts (which appear in the first positions in Google search result) a false description and a bad implementation of this stylish architecture.
The goal of this post is to briefly point some misconceptions that I found on some frequently visited blog posts. This is not an introduction to the basics of this architecture. We don’t present examples and pedagogical content. So before reading it’s a prerequisite to already know the basics. There are already excellent articles describing the architecture. There is no need to reinvent the wheel.
So, let’s begin with a succinct reminder of Hexagonal architecture’s keywords.
The building blocks reminder
The Hexagonal Architecture (also named Ports and Adapters) defines two zones: the inside of the Hexagon and its outside. The communication between the two worlds is done via a defined set of ports. The ports are defined inside the hexagon and in the outside, we define ports’ adapters.
The hexagon contains two parts which present some symmetries and asymmetries: the left and the right sides.
So let’s start with the first misconception.
What is the Inside of the Hexagon?
The first big misconception is that the hexagon is the domain. No doubt, the domain is at the heart of the architecture but the hexagon contains both the application and the domain logic. So saying that inside is the domain and the outside is application do not match with the original definition.
The goal of the Hexagon is to encapsulate the part that is independent of external peers. The application layer should be reused between several adapters of the same port. For example, if we have two adapters (REST and SOAP) for a single port, the application logic should not be duplicated in the two corresponding adapters. It should reside inside the Hexagon. And this is the essence of the Service Layer pattern.
So we can say that the left side of the hexagon is the application of the service layer pattern (see Use Cases And The Application Boundary section).
Some people declare that the Hexagon should be the domain and not the application. This reminds me of Martin Fowler’s tweet about Continous Integration:
By definition, the Hexagon is the application. You can’t change a definition of a well defined and documented concept. If you want to do that you have to create a variant of the architecture and give it another name.
The next misconception is about the right side of the Hexagon.
How to implement the right side?
The Hexagonal architecture is simple but some implementation deviates from this fundamental characteristic when implementing the right side adapters. So, instead of just implementing the interface defined in the domain layer, the implemented adapter will delegate to another object having the same level of abstraction and even the same signature. This implementation becomes has the same complexity as a GoF adapter but without having its advantages. To be more precise, I’ve seen this problem in implementations of Repositories based on Spring Data. In the last section, we’ll discuss a little more the GOF Adapter pattern in the Hexagon Architecture.
Next, we discuss a misconception about ports.
Ports are interfaces?
Often, we describe the ports as interfaces (in Java sens). But, this is not a precise statement. There is an asymmetry between the right and left side ports. The right side port should be defined using an interface. But, for the left side, it’s not recommended to define the port as an interface if it’s a header interface and not a role interface. In his sample code, Alistair didn’t use an interface for the left side port example (even if in his poetry example, he used an interface).
Our last point will be the use of the GOF adapter pattern.
What about the adapters?
In the original article, Alistair noted that the GoF Adapter Pattern is related to the architecture. But, this doesn’t mean that all the adapters of the ports are GoF adapters. Only the primary adapters implement the GoF pattern. The secondary adapters are not always an implementation of the GoF one even if they are named with the same name.
Conclusion
Even there are errors in many articles describing the Hexagonal Architecture, there are also excellent articles. One of my favorite articles is this one. But, the reference stays Alistair’s posts. We should read them before any other ones.
Finally, if we read in a post that the hexagon contains the business logic, the inner of the hexagon is the domain or the outside is the application, we should move to another post :)
