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 uma resposta

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:

What kind of optimizations could we expect from the C# compiler and the JIT? In this post, I would like...
Outro dia, tive o prazer de trocar ideias com um pessoal super interessante sobre microsserviços. Esse bate-papo ficou registrado em...
Em um post anterior, indiquei que um servidor de identidades seria uma bela alternativa para um “primeiro microsserviço”. Neste post,...
Recentemente, compartilhei uma excelente palestra, do Feredico Lois, colega no desenvolvimento do RavenDB, sobre padrões para alta performance com C#....
Nesse ano, palestrei na APIX sobre microsserviços. Abaixo, registro em vídeo feito pela organização do evento. Comentários? Feedback?
As professionals, we should focus on developing great technical solutions. But, these solutions need to solve real problems. At the...