In doing so, you isolate the central logic (the core) of your application from outside concerns. Because of loose coupling the input to business logic could be
- a web app,
- a console test application,
- a testing framework
this makes hexgonal architecuture very well suited for testing / staging environments.
the output like
- database
- redis,
- messaging
- email service
- sms service
can be swappable eg in staging environment you would not want to actually send eamils, hence there could be a dummy email service.
Imagine a hexagon shape with another, larger hexagon shape around it. The center hexagon is the core of the application (the business and application logic). And each side of the inner hexagon represents the ports/interface. The layer between the core and the outer hexagon is the adapter layer. Hence for supporting a new input communication method a new adapter has to be written which uses the interface api . The core business logic was not touched. Hence in some sense the system is core surrounded by interfaces to the outside world. For input the interfaces /ports are implemented by the core and for output the interfaces/ports are implemented by the adapter.
Image reference : https://vaadin.com/learn/tutorials/ddd/ddd_and_hexagonal
ie
- Input interfaces are called primary interfaces/ports , Driving Adapters will use a input/primary Port and an Application Service will implement the Interface defined by the Port, in this case both the Port’s interface and implementation are inside the Hexagon.
- Output interfaces are called secondary interfaces/ports, Driven adapters will implement the output/secondary port and an Application Service will use it, in this case the Port is inside the Hexagon, but the implementation is in the Adapter, therefore outside of the Hexagon.
Note that hexagon has no special meaning per se. the only point is that there will be multiple interfaces/ports and adapters. one edge of the hexagon(port/interface) represents one reason to talk to the external world. in other words 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. There may be port/interface for
- synchrnous communication
- asynchnous communication
- test application
- handling events in event based architecture (eg kafka adapter )
- handling a protocol like rest. the rest adapter will allow rest clients to interact with business logic server.
Layered architecture
In the Layered architecture application is split into at least three distinct areas of code:
- Presentation - code that handles ui
- Business Logic - handles core domain logic (eg in the j2ee architecute, ejb were handling domain logic)
- Persistence - dao classess that implement repository interfaces.
Each layer has well defined responsibilities , separation of concerns is a key advantage of this approach. The different layers can be handled by different teams (front end team typically handles presentation layer, back end team handles business logic and persistence layer). How ever it does have the disadvantage that it does not represent the fact that app is likely to be used by more than one user interface/database and typically the coupling between the layers is tight. so testing with a differnt input (like testing from commandline) becomes difficult.
Advantage of hexgonal architecture
The advatnage of hexagonal architecture over n layer / tier architecture is that hexagonal architecture has a very strong emphasis on decoupling of external inputs/outputs from the core business logic hence
- business logic is the centerpiece of architecture and focus is on deciding what is inside and outside hence the risk that business logic will infiltrate user interface code is reduced. (ie what ever should be inside will not leak outside)
- reducing chances that change in UI will impact the core business logic.
- note that completely eliminating is not easy for example if the ui wants to paginate and show results this is likely to change the business logic layer code.
- makes all external compoenets swappable and hence easy to test , create test and staging environments
- swapping technologies becomes easier/ eg moving from one sms service provider to another or one database to another.
- In theory if we have followed the hexagonal architecture our domain model will not be driven by the peculiarities of how our data is stored in a relational database.
- this achives one of the core intent of hexgonal architecture as stated by alistair cock burn (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)
Note that since frameworks by definition want to be in control hence use of frameworks as much as possible should be in the adapter so that domain model is clean. Libraries are less intrusive so they can be used.