Hexagonal and Onion Architecture - JU-DEV-Bootcamps/ERAS GitHub Wiki

Hexagonal Architecture

image

Hexagonal architecture, also known as Ports and Adapters, is a software design pattern that promtes separation of concerns and ensures your application is easily testable, maintainable, and adaptable to differet interfaces and technologies.

Key Concepts of Hexagonal Architecture

  1. Core Domain (Business Logic):
  • The application's central part, containing business rules and domain logic.
  • Independent of any external systems or frameworks.
  1. Ports:
  • Define interfaces that drive or are driven by the core domain.
  • Act as entry points (input) or exit points (output) for the application.
  1. Adapters:
  • Implement the ports and interact wih external systems, such as databases, APIs, or user interfaces.
  1. Decoupling:
  • External dependencies are separated from business logic, ensuring flexibility and reducing tight coupling.

When to use Hexagonal Architecture

Hexagonal Architecture is ideal when:

  • Your application interacts with multiple external systems or interfaces.
  • You want to make the application adaptable to future changes.
  • Testability is a priority, as the design enables unit testing without dependencies.
  • You aim to reduce the risk of technology lock-in.

Pros and Cons

Pros

  • Testability: Business logic can be tested independently of external systems.
  • Maintainability: Clear seperation of concerns simplifies updates and debuggin.
  • Flexibility: Easy to add or swap technologies, such as replacing a database or a user interface.
  • Scalability: Adapters can scale independently without affecting the core.

Cons

  • Complexity: Adds an extra layer of abstraction, which might be unnecessary for simple applications.
  • Steep Learning curve: Requires understanding of design principles, ports, and adapters.
  • Overhead: May introduce additional development effort in projects with limited scope.

Example Hexagonal Architecture in C# .NET

MyHexagonalApp/
|-- Core/
|   |-- Domain/
|       |-- Entities/
|       |-- Services/
|-- Application/
|   |-- UseCases/ 
|   |-- Ports/
|       |-- Input/
|       |-- OutPut/
|
|-- Adapters/
|   |-- Controllers/

Resources

Onion Architecture

image

It is an architecture variant of Clean Architecture that focuses on organizing code into concentric layers, where the core of the system is at the center and the outer layers represent different levels of abstraction and implementation details.

One of the key differences between Onion Architecture and Clean Architecture is how they approach the dependency management problem.

In Onion Architecture, dependencies flow from the outer layers toward the innermost core layer. This means the core layer is entirely decoupled from the outside world and can be tested independently of other components.

Clean Architecture places a particular emphasis on using interfaces to decouple components, allowing components to be easily swapped out or replaced.

Onion Architecture explicitly separates technical concerns from business logic by placing them in the outer layers of the application.

image

Onion example folder structure

src/
|-- Domain/
|   |-- Entities/
|   |-- Repositories/
|   |-- Services/
|-- Application/
|   |-- UseCases/ 
|   |-- Dtos/
|   |-- Mappers/
|-- Infrastructure/
|   |-- Persistence/
|   |-- Services/
|   |-- External/
|-- Presentation/
|   |-- Controllers/
|   |-- Views/
|   |-- Routes/