Hexagonal Architecture- Ports and Adapters
What is one of the biggest fear of a developer?
— You want to upgrade the tech stack of your application but the business logic is so tightly coupled with the infrastructure, you are sweating to touch it.
Hexagonal Architecture is the answer. Also known as “ports and adapters pattern”. The Hexagonal Architecture created by Alistair Cockburn ensures the re-usability of the business logic by making it technical-agnostic. So, changing the stack will have no impact on the domain code.
The most important constraint : The domain should depend on nothing but itself.
Why it is also called “ports and adapters pattern”?
The domain will interact with external entities through ports and adapter.
* The protocol for a port is given by the purpose of the conversation between the two devices.
* Adapter adapts the external entity accordingly to the the protocol of the port.
The hexagon is not a hexagon because the number six is important, but rather to allow the people doing the drawing to have room to insert ports and adapters as they need, not being constrained by a one-dimensional layered drawing. The term ‘’hexagonal architecture’’ comes from this visual effect.
The term “port and adapters” picks up the ‘’purposes’’ of the parts of the drawing. A port identifies a purposeful conversation. There will typically be multiple adapters for any one port, for various technologies that may plug into that port.
Now as we understand what it is , the next question is
Why should we use Hexagonal Architecture?
- The most important reason is, our business logic is completely free of any infrastructure implementation. Until our business logic changes, there is no need to touch the inside of the hexagon.
- Upgradation of technical stack is risk free. As we are not touching the code inside of the hexagon, there is no fear of any business logic bug introduction.
- Hexagonal Architecture enables us to follow Domain Driven Design as per rules.
- Enables us to write cleaner code with TDD and BDD. As there is no infrastructure dependencies, the code inside the hexagon is very easily testable with unit tests.
How can we implement all these ports and adapters in code?
Here is an example of a simple hexagonal microservice.
As we can see,
- The ports are the interfaces and adapters are the implementation of those interfaces.
- The domain has all the business logic in one place and no dependency on any infra tech stack
- Domain code is purely the language we are are using. Nothing else!!
- Writing unit test cases in domain is very simple.
How to keep our domain bug-proof?
As domain consists of simple business logic and data-models, by following TDD each and every line of code should be covered by unit tests. Moreover as all the business logics are in the domain, we can write functional test cases around the domain preventing from functional regression bugs.
As like all architectures, there are few scenarios where using a hexagonal architecture can be an overkill, like
* If the application has very simple domain simple implementation, or integration services.
* It will effectively duplicate the number of classes on the boundary.
To conclude, the main idea of Hexagonal Architecture is decoupling the core business logic from the inputs and outputs. It helps to free our most important code from the technical jargon and to achieve flexibility and testability that makes our development cycle more efficient.
