Hexagonal Architecture is an architectural style that describes a software’s design with inbound-outbound ports and adapters rather than a unidirectional layered architecture. This approach enables a more controlled asymmetry, but still an asymmetry, than a layered architecture may cause.
Ports? Adapters?
Ports and adapters are a common analogy to things that communicate with each other via a common protocol. Well, that actually may pass as one of their definitions.
In the context of Hexagonal Architecture they are the key components which decouples the business logic form external entities.
Ports are interfaces that enables the external entities to communicate with core of application (business logic).
Adapters are the entities that interact with the business logic by sending/recieving “signals” to ports.
Hexagonal Architecture *
Simple, right? This is why Hexagonal Architecture is also known as Ports&Adapters.
However, our job is not done yet, we also want to define the flow. For this we have to explain a bit about the bidirectional nature of ports and adapters.
Inbound Ports are the ports that are invoked by signals sent by inbound adapters.
Outbound Ports are the ports that are invoked by application to activate a functionality for outbound adapters.
Inbound Adapters are callers of inbound ports so that some functionality is fulfilled that is required by the adapter.
Outbound Adapters are called by outbound ports so that a functionality that business logic requires gets fullfilled.
Sometimes you will see Inbound Adapters and Ports reffered as Driving Adapters and Ports or Primary Actors.
Also you may see Outbound Adapters and Ports as Driven Ports and Adapters or Secondary Actors.
Ultimately, nobody cares how you call them.
Why bother?
Fair enough, usually three-layered architecture(s) are good enough, they are fast-to-develop, they don’t make you learn intricacies, which they don’t have many to begin with and they just make sense.
Testing: This is the main benefit of hexagonal architecture. It makes testing much easier because of your systems are no longer being coupled with external systems, you don’t have to worry about changes in your external systems. When you test your application, you are testing your application only.
Scaling: Hexagonal architecture also helps with scaling and works great with microservices architecture and domain-driven design which also are very scaling-friendly concepts.
Data protection: Hexagonal architecture prevents data leakage from inside to outside which may happen in a layered architecture because of tightly coupled functionalities.
Fine-grained systems: The applications that employ a hexagonal architecture are very modular. Code is very easy to navigate and consistent between implementations which makes it easy to understand for developers that work on different services who may want to collaborate or join the team.
Downsides
Overhead: Lots of “boilerplate” elements are added with hexagonal architecture, like ports, adapters and their pairs on both hands of application.
Complexity is subjective: Although it makes it easier for teams to work on and develop different services, it may have a reverse effect on a much smaller team that doesn’t need the extra services and may lengthen the development process.
Further reading
https://alistair.cockburn.us/hexagonal-architecture/
Get Your Hands Dirty on Clean Architecture, Tom Hombergs