Menu
Hexagonal Architecture promotes the separation of concerns by encapsulating logic in different layers of the application. This enables a higher level of isolation, testability and control over your business specific code. Each layer of the application has a strict set of responsibilities and requirements.
Conclusion. The Hexagonal or Ports and Adapters Architecture, is not the silver bullet for all applications. It involves a certain level of complexity, that when handled with care, will bring great benefits to your system. But if broken windows are allowed, it might cause a lot of headaches.
The hexagonal architecture is based on three principles and techniques: Explicitly separate User-Side, Business Logic, and Server-Side. Dependencies are going from User-Side and Server-Side to the Business Logic. We isolate the boundaries by using Ports and Adapters.
The center hexagon is the core of the application (the business and application logic). The layer between the core and the outer hexagon is the adapter layer. And each side of the hexagon represents the ports. It's not as if there are six-and only six-ports in the hexagonal architecture.
From http://alistair.cockburn.us/Hexagonal+architecture and https://github.com/jschairb/sandbox/wiki/HexagonalArchitecture
Hexagonal Architecture is an architecture defined by establishing a perimeter around the domain of your application and establishing adapters for input/output interactions. By establishing this isolation layer, the application becomes unaware of the nature of the things it's interacting with.
Create your application to work without either a UI or a database so you can run automated regression-tests against the application, work when the database becomes unavailable, and link applications together without any user involvement. - Alistair Cockburn
Are you refering to Hexagonal design pattern?
Intent of Hexagonal design pattern
Allow an application to equally be driven by users, programs, automated test or batch scripts, and to be developed and tested in isolation from its eventual run-time devices and databases.
As events arrive from the outside world at a port, a technology-specific adapter converts it into a usable procedure call or message and passes it to the application. The application is blissfully ignorant of the nature of the input device. When the application has something to send out, it sends it out through a port to an adapter, which creates the appropriate signals needed by the receiving technology (human or automated). The application has a semantically sound interaction with the adapters on all sides of it, without actually knowing the nature of the things on the other side of the adapters.
Read more about it at here
Backup version of the article here : https://staging.cockburn.us/hexagonal-architecture/
From my understanding its a bit of a buzz-word for the general software engineering practice of separation-of-concerns. It basically states that your i/o logic should be hidden from your domain logic. So you core business logic can be adapted to different "users". Its very closely related to the MVC pattern.
I think the "Hexagonal Architecture" name has just be made up by the presentor. And some people are picking it up.
This is more like an overall system design. You basically want your code to be equally friendly to all comers.
To support that, for example, webservices conform to standards and generally, universally, support JSON. Why? Webclients come in all forms so following standards allows your clients to easily integrate. JSON takes it a step further: It makes dropping a UI on top painless.
From a technology perspective you can't totally build a future-proof service. Just make sure the objective of the service is clear/clean and true to purpose. If that purpose no longer suites then you need (a) new service(s)
This is easier said than done. When you start to get leaned on by your boss to compromise these principles for the sake of expediency you do what you must to get him/her off your back. But, the hack is done and generally the result is that the service takes on unrelated logic that it permanently ends up owning.
If you can drive one principle into your system design it's this: Open for extension. Closed for modification
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With