Hexagons or Layers?
A hexagonal architecture is an alternative to a layered architecture. In a layered architecture there is a layer in which the UI is implemented and a layer in which the persistence is implemented. In a hexagonal architecture there are adapters that are connected to the logic via ports. A hexagonal architecture enables more ports than just persistence and UI. The term “adapter” illustrates that the logic and the ports are supposed to be separate from the concrete protocols and implementations of the adapter.
Figure 9.3 Overview of Hexagonal Architecture
Hexagonal Architectures and Microservices
It is very natural for hexagonal architectures to offer logic not only to other microservices via a REST interface but also to users via a web UI. This concept is also the basis of microservices. They are supposed to not only provide logic for other microservices but should also support direct interaction by users through a UI.
Since individual test implementations can be implemented for all ports, the isolated testing of a microservice is easier with a hexagonal architecture. For this purpose, test adapters just have to be used instead of the actual implementation. The independent testing of individual microservices is an important prerequisite for the independent implementation and the independent deployment of microservices.
The logic required for resilience and stability (see section 9.5) or Load Balancing (section 7.12) can also be implemented in the adapter.
It is also possible to distribute the adapters and the actual logic into individual microservices. This will result in more distributed communication with its associated overhead. However, this does mean that the implementation of the adapter and kernel can be distributed to different teams. For instance, a team developing a mobile client can implement a specific adapter that is adapted to the bandwidth restrictions of mobile applications (see also section 8.1).