What is hexagonal architecture and why implement it ?
The choice of architecture for your web or mobile application is generally made at the start of a project, during the technical design phase. This element determines how you will solve recurring design problems for your application, business representation, unit testability, and integration. This architecture is also crucial for the longevity of the application you are developing. For a business application development agency or a mobile application development agency, it is the Lead Developer's role to define this architecture.
There are several models of architectural patterns, or design patterns. Strategic patterns, which help to know how to build your application (their use is recommended for identifying business contexts), and tactical patterns, which help to build the product correctly. Hexagonal architecture, the subject of this article, belongs to this second category, just like Domain Driven Design (DDD).
Hexagonal architecture, an application design model focused on business
The origin of hexagonal architecture
Alistair Cockburn, a co-signatory of the Agile Manifesto in 2001, is behind hexagonal architecture. The objective of this architectural pattern, created in 2005, is to avoid the problems encountered with MVC (Model-View-Controller) type architectures, which involve a mix of layers (dependency of view and model, controller and view, model and controller) making unit testing and code maintenance difficult. This also impacts application performance.
This type of model complicates modifications to business logic, potentially leading to regressions and side effects detrimental to application integrity.
Hexagonal architecture corresponds to the concept of clean architecture. It aims to reduce the dependencies of business logic on technical infrastructures to maintain application stability throughout its lifecycle (update and test phase), as well as during technical evolutions of the infrastructure.
The basic principles of hexagonal architecture
The principle of hexagonal architecture is based on :
The explicit separation of the three layers that make up the architecture. At the centre of the hexagon, the business logic is the core of the reactor. Outside the hexagon is the infrastructure. It is composed of the user-side, grouping all elements that will query the domain (user console, controller, REST layers, Event Streaming, Batch Launcher, etc.), and the server-side, corresponding to all elements (information/services) the application needs to function (database, file system, web services...).
Dependencies, which flow exclusively from the outside, user-side and server-side bricks, towards the domain.
Interactions between the infrastructure and business parts, which are managed by ports and adapters API (Application Programming Interface) and SPI (Service Provider Interface).
APIs and SPIs are inside the hexagon and only manipulate the domain's business objects. APIs provide interfaces for querying the domain, and SPIs concentrate the interfaces necessary for the domain to retrieve data from third-party modules. These interfaces are utilised within the hexagon and are implemented by the server-side infrastructure elements.
Hexagonal architecture is also known as Ports & Adapters Architecture. The domain's communication ports are the APIs and SPIs, and the adapters are the infrastructure modules that implement and use them.
The principle of this architecture is therefore to isolate the business logic, which is inside the hexagon, from the technical processes which are outside, with the hexagon representing a boundary between technical code and business code. There are no dependencies between these two worlds. The business domain is strictly independent of technical elements such as communication protocol management, flows, presentation (user interface logic), etc. For this, design work is done upstream to identify all that constitutes the business logic and position these elements inside the hexagon.
The benefits of using a hexagonal architecture
Independence of business and technical infrastructure layers
The main advantage of hexagonal architecture is to guarantee the independence of the business brick, located inside the hexagon, from the infrastructure part positioned outside. By isolating the business code from the rest of the application, this architecture guarantees the reusability of the business representation.
100% testability of the business domain
Another advantage of hexagonal architecture is its testability. As all technical infrastructure and integration issues are handled independently, functional tests interact directly with the business domain, without interference from other layers.
The testability of the business domain is thus increased, with 100% coverage via unit tests. Integration tests, which concern infrastructure aspects, are a little slower, but by being isolated, they preserve the integrity of the business domain.
Modularity and scalability
As hexagonal architecture is decoupled, it can integrate a wide variety of adapters. This powerful modularity allows different layers to coexist simultaneously without impacting the business domain.
Technical and functional evolvability
Thanks to this decoupled architecture, technical and functional evolutions are facilitated. For example, on the SPI side, during the migration from a SQL database to a NoSQL database, the rest of the application is not impacted, and the longevity of the business code is not called into question. Similarly, the latter can be implemented in another hexagonal architecture and operate with a different infrastructure.
A business approach aligned with client expectations
The business layer is the central element of the system. At the start, project teams can focus on designing the business logic and expected functionalities. They thus have a perfect understanding of the client's needs and can defer technical choices until later so that they best match the project's constraints.
Design Method
To optimise the use of hexagonal architecture, the project should start from the inside of the hexagon, the business layer. This is the application's added value for the client and the element that should guide decisions, more than pure technical considerations. Project initiation is then faster since infrastructure aspects come later, and it is then possible to deliver business functionalities more quickly.
Then, one must also focus on features rather than technical details and decide on the technical implementation just before entering the development phase. As a general rule, it is difficult to determine the most suitable technical implementation to meet needs at the start of a project. Decoupling business logic from technical infrastructure guarantees the quality of the business domain, its durability, and its robustness in the face of continuous technical evolutions.
