Hexagonal Architecture Pattern

Some years ago, Alistair Cockburn proposed this interesting pattern. Quoting his words, the primary intent 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.

As events arrive from the outside world at a port, a technology-specific adapter converts it into a usable procedure call or message and passes it to the application. The application is blissfully ignorant of the nature of the input device. When the application has something to send out, it sends it out through a port to an adapter, which creates the appropriate signals needed by the receiving technology (human or automated). The application has a semantically sound interaction with the adapters on all sides of it, without actually knowing the nature of the things on the other side of the adapters.

We could graphically represent this idea in this way:

According to this pattern, it is a good idea to design our applications with some separation between the application core, which contains the domain logic, and an outer layer of adapters through which our application interacts with the external components. Following this, Web API/MVC controllers would be good examples of adapters – they are responsible by to provide data and to handle inputs. The same applies to the repository pattern implementations which interacts with the database.

While some abstractions are useful in the domain model, they may not translate well to the message contract expected by the interacting applications. The outer layer, which contains the adapters implementations, is where we leave these abstractions and convert to the representation expected by the external components (database, user interface and so on).

A good example of this pattern implications would be the adoption of a separated model for persistence as the first option whenever necessary. Another example is the use of DTOs in the frontend.

To adopt this pattern reduces the coupling and makes the system easy to maintain. In the short term, that could increase the development costs. Anyway, this cost is easily justified in the long run.


Compartilhe este insight:

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Elemar Júnior

Sou fundador e CEO da EximiaCo e atuo como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia.

Elemar Júnior

Sou fundador e CEO da EximiaCo e atuo como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia.

Mais insights para o seu negócio

Veja mais alguns estudos e reflexões que podem gerar alguns insights para o seu negócio:

If you ask me one tip to improve the performance of your applications, it would be: Design your objects to...
Time to study again. I just started an online course at the Singularity University. If you could solve one of...
Neste post, apresento o conceito de “Dívida Técnica” (não é débito, é dívida). Explico por que nem sempre elas são...
Aprendemos que a priorização das atividades deve ser feita, invariavelmente, pelo time do negócio. Na prática, entretanto, em nosso time,...
Retomar em plenitude todas as atividades econômicas, aumentando o risco de contágio pelo novo coronavírus e, eventualmente, sacrificar uma parcela...
This is another post about how to implement a basic Search Engine. Previously, I explained: how to produce an inverted...
× Precisa de ajuda?