Hexagonal Design Pattern
Although micro-services solve many technical problems, it is time perhaps to conclude, after a few years from the launch date of this concept, that this architecture needs to be further improved, to provide a way to have a clearer vision of the functional components. That’s why many architects now use DDD decomposition.
In a classic n-tier architecture, an application consists of several conceptual layers.In contrast, Hexagonal architecture intends to shift the focus towards a different direction. It uses the notion of the inside and outside part of an application. The inside part represents the domain layer or the core business logic. Whereas, the outside part consists of possible interaction points of the application.
What is “Hexagonal Architecture”?
The main feature of “ Hexagonal Architecture “, as opposed to the common layered architecture style, is that the dependencies between our components point “inward”, towards our domain objects:
This architectural style uses a notion of ports and adapters. Port is an abstract concept, whereas the adapter is the concrete implementation of a port.
Typical example of a Layered Architecture :
Communication between the layers only goes downwards. In a strict approach, a layer can talk only to a layer directly below it, while in the relaxed approach a layer can talk to all layers below it in the layer stack.
A different view of a system…
Hexagonal architecture allows an application to driven by its users and automation scripts. It also provides an ability to develop and test in isolation. Moreover, it removes the dependency of other run-time components and database systems.
The outside world accesses the application through its ports and a technology-specific adapter. An adapter converts the request into a usable procedure call. It then forwards it to the application core for business processing. For outward communication, it uses the same port and adapter pattern.
Let’s have a look at each of the stereotypes in this architecture style.
Domain Objects
In a domain rich with business rules, domain objects are the lifeblood of an application. Domain objects can contain both state and behavior.
Domain objects do not have dependencies with other layer of the application henceforth changes in the application layer don’t affect them. They are prime example of Single Responsibility Principle (the “S” in “SOLID”), which states that components should have only one reason to change.
Ports
Ports live in your core and they define how to talk to the Core. To do so you need to plug an adapter into them that will transform the input from the outside world format to one accepted by the port.
The domain objects and use cases are within the hexagon, i.e. within the core of the application. Every communication to and from the outside happens through dedicated “ports”.
An input port is a simple interface that can be called by outward components and that is implemented by a use case.
An output port is again a simple interface that can be called by our use cases if they need something from the outside (database access, for instance).
Adapters
The adapters form the outer layer of the hexagonal architecture. They are not part of the core but interact with it.
An input adapter could be a web interface, for instance. When a user clicks a button in a browser, the web adapter calls a certain input port to call the corresponding use case.
Output adapters or “driven” adapters are called by our use cases and might, for instance, provide data from a database.
Conclusion
To sum up, we draw a boundary between the application core and interactions with this pattern. The major advantage is application core logic remains inside the defined application boundary. It does not leak to the outside world.
Published By
Originally published at https://www.linkedin.com.
