Developer Experience
10
min de leitura
27 de agosto de 2020

Uso do Padrão de Arquitetura Hexagonal

Morvana Bonin
Backend Software Engenheiro com uma forte paixão por padrões de design, código limpo e arquitetura software .
Mais sobre o autor

Com o surgimento e a crescente adoção da Arquitetura Microservice, cresce também a demanda por padrões arquitetônicos que possam ajudar a criar e implementar esses serviços. O objetivo deste posto é apresentar o padrão arquitetônico hexagonal, suas vantagens e algumas desvantagens, e como utilizá-lo. É importante lembrar que cada escolha tem um custo. Portanto, vale a pena mencionar que é recomendável conhecer várias ferramentas, suas vantagens e custos, e escolher a que tem melhor custo-benefício considerando as vantagens.

Padrão de Arquitetura Hexagonal

Há uma frase que ouvi uma vez relacionada à vida, mas que também se aplica ao desenvolvimento de software :

"Uma pessoa imatura pensa que todas as suas escolhas geram ganhos... uma pessoa madura sabe que todas as escolhas têm perdas". (Augusto Cury)

Em geral, quanto mais ferramentas você conhece e quanto mais informações você tem sobre suas vantagens e custos, você tende a fazer uma melhor escolha de qual ferramenta usar como solução de acordo com o desafio apresentado.bem, vamos entender o padrão da Arquitetura Hexagonal.

Crie sua aplicação para trabalhar sem uma UI ou banco de dados, ao qual você pode executar testes automáticos de regressão, implementar quando o banco de dados não estiver disponível e conectar aplicações sem envolvê-las. (Alistair Cockburn)

Assim começa o post, extraído da documentação do site de Alistair Cockburn, criador do padrão da Arquitetura Hexagonal ou mesmo conhecido como o padrão de portas e adaptadores.

Uma das razões para criar este padrão foi principalmente delegar a infra-estrutura e UI parte do projeto, concentrar-se na regra de negócios e torná-la funcional, além de não misturá-la, ou seja, uma regra de negócios no banco de dados ou mesmo na parte UI de um projeto.

A arquitetura hexagonal é compartilhada em 3 partes:

  • Centro do Hexágono
  • Lado esquerdo do hexágono
  • Lado direito do hexágono

Neste cenário, temos os atores que irão interagir com o centro do hexágono:

  • O ator principal, que conduzirá uma ação;
  • O ator secundário a ser liderado.

Uma pergunta comum é a diferença entre os atores: quem são os principais atores na minha aplicação? Quem são os atores secundários?

Para responder a esta pergunta, é necessário fazer outra pergunta:

"Quem inicia a conversa?

"Isto é, quem é responsável por iniciar o fluxo, o ator que realiza uma ação?

Ao responder esta pergunta, você terá os atores principais, não importa se é uma pessoa, outro sistema, um script em bash que chama seu adapter, se dispara um gatilho que chama o core business de sua aplicação, então ele é o ator principal.

Então, o ator secundário será levado a realizar uma determinada ação que o ator primário tenha desencadeado. Pode ser gravar dados, registrá-los, ou mesmo chamar uma terceira aplicação e obter uma resposta, retornando ao ator primário.

O centro do hexágono

É onde estão localizados os modelos, domínios e regras de negócios de seu software . É um ambiente que deve ser totalmente isolado em termos de não ser afetado por ocorrências externas, por exemplo, o banco de dados que será utilizado, framework frontend.

Lado esquerdo do hexágono

É o lado do ator principal, o lado do usuário, que conduz uma ação, pois este é o lado do usuário que realiza alguma tarefa.

Lado direito do hexágono

É o lado do ator secundário, lado dos dados, que é conduzido, seja para escrever dados, ler dados, modificar dados, e apagar dados.

Portas

As portas são a comunicação gateway entre o centro de seu hexágono com os lados esquerdo e direito do seu hexágono, com os lados externos.

Adapters

Os adaptadores são os usuários das portas. Para cada porta que seu hexágono possui, um adaptador deve ser criado, portanto, você tem a liberdade de modificá-lo e apagá-lo dinamicamente. Em portas e adaptadores, temos também o conceito de portas primárias e secundárias, e o conceito é o mesmo utilizado com os atores.

Nos atores primários de nossa aplicação temos os condutores da ação, que utilizarão os adaptadores primários, e isto "baterá" nas portas primárias. Assim, as portas secundárias e os adaptadores conduzirão a ação até o ator secundário no fluxo contínuo da aplicação.

Inversão de Controle (IoC)

Em um fluxo real, usando como exemplo o simples registro de dados, teríamos o seguinte:

  • O lado esquerdo (o condutor) entrega as informações, usando um adaptador e através da porta principal, ao centro do hexágono (domínio).
  • O centro do hexágono, então, recebe dados através da porta, depois os processa usando uma porta secundária e chama o lado direito.
  • O lado direito (o conduzido) chama um banco de dados para registrá-los.

No final, teríamos isto como o fluxo do Hexágono:

Lado esquerdo -> Centro -> Lado direito

Mas este cenário impacta os conceitos da Arquitetura Hexagonal, que é que o domínio deve ser isolado e responsável apenas pela regra de negócio, pois no exemplo acima, teria que ser responsável por chamar a entidade responsável pela gravação.

Agora, surge o conceito de Inversão de Controle (IoC).

Inversão de Controle (IoC) é um padrão que defende o uso de instâncias de uma determinada classe, tratando-a externamente e não dentro da classe em questão, ou seja, delegando o controle de uma classe para outra. Ela pode ser uma interface, componente, serviço, etc.

Em nosso caso, ele inverterá precisamente a ordem de fluxo, assegurando que, ainda usando o exemplo, nosso banco de dados vá para nosso centro e não para o outro lado, deixando nosso domínio realmente isolado.

No final, este seria o nosso fluxo correto:

Lado esquerdo -> Centro <- Ioc- Lado direito

Pontos positivos

Como pontos fortes da utilização desta arquitetura, podemos enumerar:

  • Solução de Serviços Externos Independentes
  • Possibilita adiar algumas decisões técnicas
  • Criação e substituição de adaptadores
  • Fácil de testar a aplicação
  • Tecnologias fáceis de trocar

Pontos negativos

Também temos alguns aspectos negativos no uso desta arquitetura hexagonal, que são

  • Complexidade adicional (construção de mais camadas)
  • Custo de criação e manutenção
  • Não há orientação sobre como organizar o código (diretórios, camadas)

Conclusão

A arquitetura hexagonal é tomada como um guia, e a partir dela, novos conceitos arquitetônicos foram criados com informações mais granulares na organização do código (diretórios, camadas), como exemplos temos a arquitetura Onion, de Jeffrey Palermo, e a Clear Architecture, de Robert C. Martin (Uncle Bob). Ambos se referem ao padrão criado por Alistair Cockburn.

Mesmo que você já tenha escolhido seguir a idéia de Jeffrey ou Uncle Bob, recomendo estudar a arquitetura hexagonal para entender o conceito de isolamento do domínio e a comunicação com seus respectivos atores. Depois disso, você verá que será mais fácil entender as idéias de outros autores que criaram novos conceitos com base nessa idéia inicial.

Obrigado pela leitura!