.svg)
Hexagonal architecture has gained a lot of popularity in recent years. Several books have been written on the theory and implementation, showing many of its benefits. However, it is still not a frequently applied pattern in software development projects. Let’s do a quick overview to better understand why!
It seems that engineers see it as a somewhat academic or enterprise pattern. The one that seems a bit like over-engineering for the majority of real-world applications. Engineers in charge of the architecture also often worry about the higher initial costs of going with hexagonal. The concerns may have some ground, yet, does its use really bring such overhead? To be honest, when compared to a quick and dirty proof of concept implementation, then yes. It will, however, most likely outpace that kind of a project within weeks, surely within a couple of months into development. That said, there is nothing especially fancy about the pattern itself. It is, in essence, a method for splitting the infrastructure code from the domain. As a result, you’ll have a much better chance your project will stay maintainable and extendable in the long run. Simply put – cheaper and faster to develop.
The Hexagon As a Boundary
The Hexagonal architecture is a software development pattern proposed by Alistair Cockburn back in 2005. It was his solution for a software project that fetched weather data from different sources. The data had to be aggregated and sent to clients no matter the source. Also, the delivery mechanisms varied from client to client. The project was struggling with a lot of code duplication, so a novel approach was needed in order for it to grow. The Ports and Adapters architectural pattern was developed and is today recognized for its memorable hexagon shape.
It is a pattern that is very straightforward to talk about and understand. The hexagon shape represents a boundary. Inside is the code that represents the business rules and services. This is the domain.
On the outside, there are all the technical code elements, such as:
- API endpoint implementations
- database connection implementations
- 3rd party services clients, etc.
They are the infrastructure.
The theory proposes using this pattern to prevent the infrastructure code on the outside from infiltrating and polluting the business code on the inside. The reasoning for this comes from the fact the pollution of the domain very often significantly slows down development. This is a form of “Tech Debt.”
The Domain Is King
To better understand the hexagonal architecture, let’s compare it with the layered architecture. The more traditional one of the two is a solid development pattern. However, layered architecture will almost inevitably suffer from the problem of infrastructure infiltration.
Here the database and presentation layers represent a part of the infrastructure, while the domain represents the business logic and services. Looking at the sketch representation of the theory below, you can quickly notice that the presentation layer depends on the domain layer. Then, further down, the domain layer depends on the database layer.
Seeing this sketch, it is obvious that our business logic depends on the infrastructure. As databases have implementation-specific limitations, they will almost inevitably impose themselves on the domain.
Hexagonal, on the contrary, treats database and presentation the same way. They are both parts of the infrastructure. In this pattern, the domain is the layer others depend on and not the other way around.
Consequently, the domain is free from all dependencies and frameworks, making it highly testable even with simple unit tests. In fact, we don’t even need any infrastructure implementations to implement and test the domain logic.
Another thing to consider with the classic layered architecture is that developers like to take shortcuts. Maintaining clean and separated layers can be expensive, so shortcuts like skipping the domain and going straight from the presentation to the database may seem innocent. However, once a shortcut is in place, it tends to grow and accumulate business logic that does not belong there. We call this “Domain Leakage,” which is again a form of tech debt.
On the other side, hexagonal is not immune to shortcuts. Nothing is stopping developers from implementing the call to the database in the presentation. Also, nothing is stopping them from implementing business logic in the infrastructure. However, imposing boundaries on developers isn’t the primary intention of this pattern. The real purpose is to give developers the tool to approach the system from the right angle with the right mindset.
With hexagonal, the database is no longer the foundation layer of our architecture where the domain seems like a lesser citizen. The domain is king. It depends on no other layer, so it is logical to start the development there. As this, in other words, endorses the implementation of the business side of code first, there is much less reason for a developer to skip steps or take shortcuts. Therefore, this type of software architecture seems like a good fit for projects that wish to model the domain free from any technological constraints.
The Many Benefits of the Hexagonal Approach
If you decide to go hexagonal, your project will:
- be easier to maintain and test
- have a good separation of important concerns
- keep the business logic independent from the infrastructure
- be cheaper and faster to develop
Besides the more obvious benefits mentioned above, the most important one when going hexagonal is that your deployment choices remain open. This means you can start your project as a monolith and later transition to microservices, which is crucial because a monolith gives you the advantage of quick feature delivery without the overhead of distributed computing.
Later, whenever the business identifies the need, microservices can be extracted with relative ease – assuming your hexagon is not one big ball of mud as you have already cleanly separated hexagons of separate bounded contexts. The topic is nicely covered in “Strategic Monoliths and Microservices,” a book by Vaughn Vernon and Tomasz Jaskuła.
Hexagonal is undoubtedly not the best fit for every project type, but it is a solid pattern with many benefits. For example, if it is vital to keep the business logic independent from the infrastructure or keep your deployment choices open, as mentioned above, and we’re not working on a proof of concept or an MVP, then going hexagonal certainly won’t be wrong.
In the end, if deciding between layered or hexagonal, then the latter certainly brings many benefits with little or no overhead.
