Hexagonal Architecture: or how to be always ready for the change

The Hexagonal Architecture, also known as Ports and Adapters, is an architectural pattern that aims to decouple your business logic from everything else. It has multiple benefits, and it is well known for providing the software with the necessary elasticity to face the continuous changes of specifications and business grow, required in an agile environment. That's one of the reasons why it's used successfully at Netflix, along with many other big companies. Here, I will try to explain why is it so loved among software engineers.

Why are software architectures needed?

Software architectures provide engineers and developers a common framework for developing quality software products. Given that the complexity of software systems has been (and is increasing) in recent years, it is essential to use clean architectures that allow us to separate responsibilities through layers and defining dependency rules between them. All this will avoid the coupling of our domain with external elements, which will ensure our software is:

• Framework-independent
• Testable
• UI-agnostic
• Database-agnostic
• Change-tolerant
• Reusable
• Maintainable

And in fact, independent of any external provider (SMS provider, mail provider, queues provider, infrastructure services, etc) not related with the core logic of our business or domain.

Motivation behind Hexagonal Architecture

The original intent of Hexagonal Architecture (by Alistair Cockburn) is:

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.

This way, we want to avoid common mistakes with software applications that every developer out there had faced at some point:

• Mixing presentation code (UI, API endpoints, ...) with business logic.
• Coupling code to infrastructure, like the database implementation.

This bring several problems:

• Difficult to automate tests
• Prevents the change of use-cases of the application.
• It hinders or prevents the use by another program.

How Hexagonal Architecture solves our problems

The main motivation of the Hexagonal Architecture is to separate our application into different layers or regions with their own responsibility. In this way, it manages to decouple layers of our application, allowing them to evolve in isolation. In addition, having the software separated by responsibilities will facilitate reuse. Thanks to this decoupling, we also obtain the advantage of being able to test these layers without the intervention of other external ones, like the database or a third party service or provider.

This architecture is usually represented as a hexagon. However, the number of sides is not what matters, but what they represent. Each side represents a port into or out of the application. For example, one port can be an API REST, exposing endpoints that allow to make requests to our application. Another can be a database where the data of our domain persists. Another can be a SMTP server or an email provider, etc.

Hexagonal Architecture proposes that our domain is the core of the layers and that it is not attached to anything external. Instead of making explicit use, and through the dependency inversion principle, we attach ourselves to contracts (interfaces or ports) and not to specific implementations.

Broadly speaking, and without much detail, what it proposes is that our core be seen as an API with well-specified contracts. We will define ports or entry points as interfaces (adapters), so that other modules (UI, database, tests, etc.) can implement them and communicate with the business layer without it having to know the origin of the connection.

That is why Hexagonal Architecture is also called Ports and Adapters, which could be defined as follows:

• Port: definition of a public interface.
• Adapter: implementation of a port for a specific context (implementation of its interface)

Hexagonal Architecture and Domain Driven Design

Being an architecture that encourages our domain to be the core of all layers (or regions), and not coupled to anything external, it fits very well with the idea of Domain Driven Design (DDD).

We could say that DDD is based on the Hexagonal Architecture as the central pillar in terms of architecture.