Organizando seu projeto .NET com Arquitetura Hexagonal — Parte 01

5 min readOct 16, 2020

Antes de começarmos a adentrar no assunto de arquitetura hexagonal, vamos, primeiro, entender alguns conceitos antes 📚.

Arquitetura de Software

Acredito ser interessante sabermos, antes de tudo, o que é Arquitetura de Software e no que isso nos auxilia. Por trás de todo sistema há uma estrutura organizacional envolvida, a qual chamamos de Arquitetura de Software. Tal conceito serve para poder ajudar a compreender a diferença entre linguagens, sistemas operacionais, ambientes, experiência de seu time tecnológico e qualquer outro componente tecnológico que possa fazer parte de uma solução. Além desses pontos importantes, vale ressaltar que, pensando neles podemos obter redução de riscos ao negócio, alinhamento de expectativas, aplicações evolutivas e flexíveis, interoperabilidades e, talvez algo que está em alta, a segurança.

Arquitetura Evolutiva

Agora que sabemos os conceitos básicos de Arquitetura de Software, penso que é importante alinharmos sobre o conceito de Arquitetura Evolutiva, algo que falamos, também, logo acima. O principal pilar para que uma arquitetura seja evolutiva é o suporte a mudanças incrementais, onde não há quebra da aplicação/arquitetura atual e não há necessidade de ter as famosas POGs (programação orientada a gambiarra). Em conjunto com esse termo, encontramos, também, o famoso DDD (Domain Driven Design) o qual nos auxilia a modularizar um sistema, através de contextos delimitados, além disso, conseguimos nos organizar em torno do que é o mais importante em um software, o negócio. Outra grande característica presente, diante deste cenário, é a possibilidade de realizar experimentações, a partir de uma arquitetura modularizada e delimitada, pode-se realizar, por exemplo, testes A/B e deploys de versão “Canary” com certa facilidade.

Arquitetura Hexagonal

Finalmente, vamos adentrar nos conceitos desta arquitetura. Mas, afinal, o que é uma Arquitetura Hexagonal?

A princípio, tal arquitetura é, nada mais nada menos do que, mais uma maneira de se organizar o código, dentro de uma aplicação, em camadas, onde cada uma há alguma responsabilidade. Contudo, existe uma característica particular nesta arquitetura em si. Ela, também, é conhecida como “Ports and Adapters”, onde o termo “Ports” (ou portas) representa as interfaces sua aplicação, utilizadas tanto para entrada e/ou saída. E os “Adapters”, seria as implementações de tais interfaces. Como exemplo de saídas, podemos destacar a comunicação com algum banco de dados, fila, logs e, como exemplo de entradas, podemos destacar o consumo da nossa aplicação através da exposição de APIs. Entendido esse conceito, temos o Core da aplicação como ponto focal, onde o acesso a ele se dá pelos “Ports and Adapters”, tais códigos são do domínio do negócio, onde neles não há interferência externa.

Mas não paramos por aqui. Nós, ainda, separamos os “Adapters” em dois tipos, os quais são os primários e secundários. Você deve ter reparado que citamos, de fato dois tipos de “casos de uso” que são as entradas e saídas. Vamos entrar um pouco mais no detalhe nesses pontos!

Adaptadores Primários

Também conhecidos como “Driving Adapters” (ou Adaptadores de Direção), representam os adaptadores de entrada, ou seja, na maioria dos casos pode representar a interface com o usuário. Isso se dá, pois eles conduzem a aplicação e iniciam ações nela. Neste caso teremos, como exemplo, controladores de APIs, controladores Web ou, simplesmente, Views.

Adaptadores Secundários

Também chamados de “Driven Adapters” (ou adaptadores acionados), representam os adaptadores de saída, ou seja, a conexão com o mundo externo. Eles reagem de acordo com as ações feitas nos adaptadores primários. Neste caso temos, como exemplo, conexões com banco de dados, APIs, bibliotecas, envios de Email e registros de Logs.

Para exemplificar tal arquitetura, veja a imagem abaixo:

Repare que como saídas, temos a comunicação com os bancos de dados da Oracle e Sql Server, além do LogStash. E como entradas, temos a exposição de uma API. O Core, contém os casos de uso, os quais são as regras de negócio, de fato, da aplicação, algo totalmente isolado e intacto ao mundo externo.

Outro ponto que vale ressaltar, é que a API, sendo um Adaptador Primário, é acionada e desencadeia algum tipo de ação e, tal ação, pode acionar os Adaptadores Secundários, como a conexão em algum banco de dados para retornar algum registro ou, até mesmo, registro de logs de todo o processamento feito.

Ponto de atenção: Os casos de uso não são algo obrigatório neste cenário, tal conceito vem do Clean Architecture, o qual é um outro assunto.

Com os conceitos sobre Arquitetura Hexagonal entendidos, o que ela tem haver com Arquitetura de Software e Evolutiva? Simplesmente tudo! Arquitetura Hexagonal foi definida de acordo com as necessidades e pontos analisados de acordo com a arquitetura de software. Com relação a arquitetura evolutiva, a arquitetura de software é considera uma. Vejamos alguns pontos explicando o porquê disso:

Caso você necessite comunicar com algo externo (saída), é fácil realizar esse “plugin”. Pois, tanto na prática quanto na teoria, você precisa criar uma Porta e um Adaptador para ela representando esse novo “plugin”. Em .NET, por exemplo, você pode realizar isso criando um projeto, de certa forma isolado, dentro da sua solução.
Caso haja mais algum consumidor (entrada), além da própria API exposta (talvez uma Aplicação Console), basta criar tal componente e conectá-lo da forma que você ache melhor na sua aplicação, utilizando, novamente, os conceitos de Portas e Adaptadores.
Você desenvolve orientado ao negócio, onde o mesmo está totalmente “protegido” do mundo externo, visando os conceitos de DDD.

Visto os pontos apresentados, podemos exaltar que essa aplicação é uma aplicação anti-frágil, pois as possíveis mudanças que virão no futuro não afetara sua estrutura, pelo contrário, será benéfico para o próprio negócio.

No próximo artigo veremos, na prática, como criar uma aplicação neste modelo arquitetural utilizando .NET 🤓! Te espero lá 😎!

— Ir para Parte 02 —