Hexagonal Architecture

The hexagonal architecture (also known as Ports & Adapters) is a quite popular concept pattern in the modern software world. Let’s check what it is and when it can be helpful.

The pattern was originally introduced by Alistair Cockburn in 2005 in his blog post Hexagonal Architecture and intended to solve the following problems:
- Undesired dependencies between system layers
- Mixed business logic with external interactions logic
- Poor business logic testability by automated integration tests

Key points of the suggested solution:
✏️ Split system representation on what is “inside” application and what is “outside”.“Inside” logic should not leak to “outside” part
✏️ Introduce “ports” - communication channels with outside entities better known as boundaries of application: contracts and interfaces
✏️ Introduce “adapters” - entities that transform one interface into another (web UI, mobile UI, databases, queue system integrations, etc.). Adapters are the components that allow the application to interact with specific technologies.
✏️ Each port can have multiple adapters
✏️ Adapters can be primary and secondary.
✏️ Primary adapters (also called “driving”) are responsible to receive external signals and convert them to a Port, such adapters initiate communication flow. Examples: different types of UI, direct calls to REST APIs, CLIs, etc.
✏️ Secondary adapters (also called “driven”) convert commands from Ports to a specific technology. Examples: read\write to database, message queue integration, storing files on s3 storage, etc.
✏️ Outside entities can interact with application only via defined ports

Usage examples: different OS support via separate adapters, integration with different types of storages like filesystem, s3, azure blob storage and others, separation of application logic and UI development, proper contracts between systems that are developed by different teams.

Pros:
- Testability improvements: it’s possible to test application logic without external dependencies
- Increased maintainability: separation of concerns and business logic decoupling make it easier to locate the code to be modified
- Flexibility: adapters can be easily swapped without any impact on core logic
- Adaptation to technology evolution: Technologies are changed more frequently than business logic. As the technology part is encapsulated in a specific adapter, it’s enough to change the adapter only.
- Put-off technologies decisions: focus on business logic, postpone decision about particular technologies for real production usage.

Cons:
- Complexity: application has a complex structure with a lot of modules and explicit dependencies defined between them
- Indirection: extra calls to methods when an adapter converts between port and specific technology interfaces
- In some contexts may be not applicable or inefficient: approach works well for cases with complex and stable business logic.

So the main idea of the pattern is to design a software around domain logic and isolate it from external factors and constantly changing technologies.

#architecture #systemdesign #patterns