Hexagonal Architecture

What is Hexagonal Architecture?

Alistair Cockburn introduced the hexagonal architecture, also known as the ports and adapters pattern, as a means of developing applications that may be equally driven by programs, users, automated tests, or batch scripts. It can also be used with any database, external agency, or user interface. By clearly defining boundaries between various system components, the main aim is to separate the application's essential business logic from its external concerns.

Ports and Adapters

Imagine your application's business logic as the hexagon with a number of ports connecting it to its external concerns. These interfaces, which external systems use to communicate with your business logic, are known as ports.

Driving ports, or primary ports, are inbound interfaces that allow external actors to interact with your application's business logic . They represent the entry points into your system.

A driving port defines what your application can do from an external perspective:

// Driving Port
public interface IUserService
{
    User CreateUser(string username, string email);
    User GetUserById(long id);
}

A driving adapter implements the driving port's interface to connect external systems. The driving adapter may be a web controller or a command line interface (CLI).

Driven ports, or secondary ports, are outbound interfaces that allow your application to interact with external systems. They represent the dependencies your application needs to function.

// Driven Port
public interface IUserRepository
{
    User Save(User user);
    User? FindById(long id);
}

A driven adapter implements the driven port's interface that connects to the external dependency such as a database or message queue.

Hexagonal Architecture vs. Clean Architecture

Hexagonal Architecture and Clean Architecture are two architectural patterns that frequently come up in conversations about creating scalable, maintainable software systems. Even though their objectives and guiding principles are similar, it is essential to understand their differences in order to make sensible architectural choices.

However, it's critical to first acknowledge the similarities between these architectures before delving into their differences. Both patterns share some core principles, viz.:

1. Separation of Concerns: Technical implementation details are kept apart from business logic.
2. Dependency Inversion: High-level modules don't depend on low-level modules.
3. Testability: It is possible to test core business logic without relying on external systems.
4. Flexibility: Affords switching external implementations such as UI frameworks or databases.

Hexagonal architecture has business logic at center, surrounded by ports and adapters whereas clean architecture, popularized by Robert C. Martin (Uncle Bob), emphasizes a strict layered structure where each layer has specific responsibilities and dependencies flow inward.

The key differences between the hexagonal architecture and clean architecture is shown in the table below:

Benefits of Hexagonal Architecture

The beauty of well-architected systems lie in their ability to deliver multiple benefits simultaneously, creating a development experience that becomes increasingly valuable over time.

By using adapters instead of mock adapters, developers can quickly and simply validate business logic from a testing standpoint. This allows for thorough test coverage without the hassle of integrating with real databases, APIs, or third-party services. Because of the flexibility offered by this architectural approach, teams can change implementations without affecting the core business logic that determines how the application functions, such as when transferring payment processors or databases.

Because developers don't have to navigate through tightly coupled code that spans multiple concerns to modify or debug specific components, the system is extremely maintainable due to the clear separation of concerns that underpins this design.

When it comes to growth, these systems scale gracefully by making it straightforward to add new interfaces or integrate with external systems through additional adapters, whether for mobile apps, web services, or partner integrations.

Most significantly, the core business logic is independent of particular databases, frameworks, or technologies. This means that the core business rules that encode years of domain expertise remain reusable and unaffected when the organization chooses to upgrade its tech stack or move to new platforms.

Practical Implications

When speed and clarity is crucial the hexagonal architecture is an ideal option. The ports and adapters approach provides a clear mental framework that will appeal to developers who might be unfamiliar with architectural patterns or working under pressure and wants an easier-to-understand model. Because the port-based design naturally supports these varied connections, this architecture excels in systems with multiple integration points, where the application must interface with multiple external systems, including databases, APIs, messaging queues, and different user interfaces.

Organizations can avoid the learning curve associated with more complex architectural approaches by using the ports and adapters pattern to implement solutions more quickly. Additionally, the relatively simple structure of Hexagonal Architecture enables teams to build, test, and refine their systems without becoming bogged down in intricate layering decisions or stringent dependency management rules when rapid prototyping is the main objective and the need for quick implementation and iteration takes precedence over long-term architectural rigor.

When projects call for complex structural organization and long-term sustainability, Clean Architecture becomes the best option. Clean Architecture's explicit layering approach is especially useful for applications with complex business logic because it offers a clear organizational framework that distinguishes between enterprise-wide business rules and application-specific operations, making it simpler to navigate and comprehend complex domain requirements. Since the clear divisions between entities, use cases, interface adapters, and frameworks result in maintainable systems that can handle the scale and complexity typical of enterprise environments, large enterprise applications naturally fit this architectural style.

Clean Architecture is particularly useful for organizations with stringent governance requirements because it offers the architectural discipline required to preserve uniformity across sizable development teams and lengthy project lifecycles.

Conclusion

The key lesson is that your application's business logic should define its own interfaces for interacting with the outside world, rather than being coupled to specific technologies or protocols.

Remember, the goal isn't to over-engineer but to create clear boundaries that make your system easier to understand, test, and modify.