Understanding Hexagonal, Clean, Onion, and Traditional Layered Architectures: A Deep Dive
Anarchitecture refers to the segmentation of a system into parts, the organization and attributes of these parts, and the manner in which these parts interact with each other.
An effective software architecture ensures that the software can be modified throughout its lifespan with minimal, consistent effort, resulting in predictable costs for the client.
Changes might include:
- Fulfillment of client requests
- Modifications to comply with changes in legal regulations
- Adoption of newer technologies
- Upgrading infrastructure elements
- Switching third-party systems
- Even substituting the application server
Hexagonal, Clean, Onion, and Traditional Layered Architectures are examples of architectural styles that apply to the internal structure of a software application. They are based on the principle of separation of concerns, which means dividing the application into distinct layers or modules that have different responsibilities and dependencies.
The main difference between these architectures is how they define the boundaries and interactions between the layers or modules.
High Level Comparison
Hexagonal Architecture vs Layered Architecture
The Layered Architecture is criticized for its focus on the database, leading to issues such as transitive dependencies, blurred layer boundaries, poor component isolation, and difficulties in testing, maintaining, and swapping infrastructure components. This approach is referred to as database-driven design, where the application is planned around a database.
On the other hand, the hexagonal architecture, emphasizes business logic over database design. It’s more logical to plan and develop the business side of an application first and consider data persistence later. Changes in business logic should drive changes in data persistence, not vice versa.
As applications grow more complex and incorporate additional components like REST APIs and third-party services, the hexagonal architecture provides clear guidelines for where these components belong. In contrast, a layered architecture often results in increased dependencies and potential duplication of business logic.
Hexagonal Architecture vs Clean Architecture
The “Clean Architecture” also places business logic at the center, similar to the Hexagonal Architecture. Interface adapters surround this core, connecting it with the user interface, database, and other external components. The core is only aware of the interfaces of these adapters and not their concrete implementations.
In Clean Architecture, all source code dependencies point towards the core. The Dependency Inversion Principle is applied when calls point from inside to outside, opposite to the source code dependency direction.
The Hexagonal Architecture can be almost directly mapped to the Clean Architecture:
- Eexternal agencies around the outer hexagon correspond to the outer ring of Clean Architecture, “frameworks & drivers”
- Outer hexagon adapters match the “interface adapters” ring in Clean Architecture
- Application hexagon aligns with the “business rules” in Clean Architecture. These are further divided into “enterprise-related business rules” (entities) and “application business rules” (use cases that orchestrate entities and control data flow). However, Hexagonal Architecture leaves the architecture within the application hexagon open
- Ports are not explicitly mentioned in Clean Architecture but are present in associated UML diagrams and source code examples as interfaces
Hexagonal Architecture vs Onion Architecture
The Onion Architecture places the business logic at the center, known as the “application core”. This core interfaces with the user interface and infrastructure but is unaware of their concrete implementations, isolating it from the infrastructure.
Like the Hexagonal and Clean architectures, all source code dependencies in the Onion Architecture point towards the core. Dependency inversion is applied when the call direction opposes the source code dependency.
The Hexagonal Architecture can be almost directly mapped to the Onion Architecture:
- External agencies around the outer hexagon correspond to the infrastructure components in the Onion Architecture
- Outer hexagon adapters match the ring containing “user interface”, “tests”, and “infrastructure” in the Onion Architecture
- Application hexagon aligns with the application core in the Onion Architecture, which is further divided into “application services”, “domain services”, and “domain model”. Only the “domain model” is a fixed component of the Onion Architecture, with other rings marked as optional. The “domain model” defines the “enterprise business rules”, corresponding to the innermost circle or “entities” ring of the Clean Architecture
Conclusion
Hexagonal, Clean, and Onion Architectures are alternative architectural styles that can help you design more modular, testable, and scalable applications. However, they also come with some trade-offs that you need to consider before adopting them. There is no one-size-fits-all solution for software architecture, so you need to choose the style that best suits your project’s requirements and constraints.
