Arquitetura Hexagonal

Prévia do material em texto

Padrão de Arquitetura Hexagonal
Com o advento e crescimento da adoção da Arquitetura de Microsserviços, também cresce a procura por padrões arquiteturais que possam ajudar na criação e implementação desses serviços. A escolha de um padrão arquitetural pode auxiliar muito nessa jornada. A ideia deste artigo é mostrar um pouco sobre o padrão de arquitetura Hexagonal e explicar suas vantagens e algumas desvantagens e como utilizá-lo.
 
Lembrando que não existe bala de prata e toda escolha traz um custo, então vale ressaltar que é aconselhável conhecer várias ferramentas, suas vantagens e custos e escolher aquela que o custo seja baixo perto das vantagens.
Padrão de Arquitetura Hexagonal
Há uma frase que escutei certa vez para vida, mas trouxe para dentro do desenvolvimento de software também, e o que para mim faz sentido, que diz o seguinte:
 
“Uma pessoa imatura pensa que todas suas escolhas geram ganhos… uma pessoa madura sabe que todas as escolhas tem perdas.” (Augusto Cury)
 
Em suma, como disse anteriormente e reforçando, quanto mais ferramentas você conhecer, mais sobre suas vantagens e custos, tende a fazer uma melhor escolha de qual utilizar como solução diante do desafio apresentado.
 
Bom, sem mais delongas, vamos ao conhecimento do padrão de Arquitetura Hexagonal.
 
Crie sua aplicação para funcionar sem ter nem uma UI ou base de dados, ao qual você pode rodar testes de regressão automatizado, implemente quando a base de dados não está disponível e conecte aplicações sem envolver elas. (Alistair Cockburn)
 
Assim começa o artigo, documentação no site de Alistair Cockburn, criador do padrão de Arquitetura Hexagonal ou ainda conhecido como padrão de portas e adaptadores.
 
Um dos motivos da criação desse padrão foi principalmente delegar a parte de infraestrutura e UI (User Interface) do projeto e se preocupar com a regra de negócio e em deixá-la funcional, além de, não misturar ela, ou seja, regra de negócio na base de dados ou mesmo na parte de UI de um projeto.
 
A arquitetura hexagonal se divide em 3 partes
· Centro do hexágono
· Lado esquerdo do hexágono
· Lado direito do hexágono
 
Nesse cenário temos os atores que irão interagir com o centro do hexágono, temos 2 atores
O ator primário o que irá conduzir uma ação
O ator secundário que irá ser conduzido.
 
Uma dúvida comum é a diferença entre os atores, quem são os atores primários de minha aplicação? Quem são os atores secundários dela?
Para responder essa pergunta é necessário fazer outra “Quem inicia a conversa?”, ou seja, quem é o gatilho que inicia o fluxo, que faz uma ação?
 
Ao responder essa questão você terá os atores primários, não interessa se é uma pessoa, um outro sistema, um script em bash que chama seu adapter, se ele aciona um gatilho que chama o core business de sua aplicação, então ele é o ator primário.
 
O ator secundário será então conduzido a executar uma determinada ação que o ator primario disparou, sendo gravar dados, logar eles, ou mesmo chamar ainda uma terceira aplicação e obter uma resposta, retornando ao ator primário.
 
O centro do hexágono
É onde se situam seus modelos, domínios, regras de negócio do seu software, é um ambiente que deve ser totalmente isolado em termos de não ser afetado por ocorrências externas, exemplo, banco de dados que será utilizado, framework frontend.
 
Lado esquerdo do hexágono
É o lado ator primário, user-side, que conduz uma ação, sendo esse o do usuário que executa alguma tarefa.
 
Lado direito do hexágono
É o lado do ator secundário, data-side, que é conduzido, seja para gravar dados, ler dados, modificar dados e deletar dados.
 
Portas 
As portas são a ponte de entrada de comunicação entre o centro do seu hexágono com os lados esquerdo e direito do seu hexágono, com os lados externos.
 
Adapters
Os adapters são os utilizadores das portas, para cada porta que seu hexágono tiver um adapter deve ser criado para que você tenha a liberdade de modificá-lo, deletá-lo de forma dinâmica.
 
Em portas e adapters também temos o conceito de portas primárias e portas secundárias e o conceito é o mesmo explicado sobre os atores, nos atores primários de nossa aplicação temos os condutores da ação que irão usar os adapters primários e esse por sua vez irão “bater” nas portas primárias, sendo assim as portas e adapters secundários irão  conduzir a ação até o ator secundário em um fluxo contínuo da aplicação.
 
Inversão de Controle (IoC)
Em um fluxo real, usando como exemplo a simples gravação de um cadastro, nesse cenário, teríamos o seguinte:
· O lado esquerdo (o condutor) entrega a informação, utilizando um adapter e através da porta primária, para o centro do hexágono (domínio).
· O centro do hexágono, por sua vez, recebe através da porta os dados, os processa em seguida utilizando uma porta secundária e chama o lado direito.
· O lado direito (o conduzido) chama uma base de dados para gravar eles.
 
No final teríamos isso como fluxo do Hexagono:
Lado esquerdo -> Centro -> Lado Direito
 
Mas esse cenário fere um dos conceitos da Arquitetura Hexagonal, que é a de que o domínio deve ser isolado e cuidar apenas da regra de negócio, isso por que no exemplo acima, ele teria de cuidar de chamar quem faz a gravação.
 
Para isso nós utilizamos o conceito de inversão de controle, do inglês Inversion of Control (IoC).
 
Inversão de controle é um padrão que prega para usarmos instâncias de uma determinada classe, tratando-a externamente e não dentro da classe em questão, isso significa, delegar o controle de uma classe para outra, pode ser de interface, componente, serviço, etc.
 
Em nosso caso, irá justamente inverter a ordem de fluxo, fazendo com que, ainda utilizando o exemplo, nossa database vá até o nosso centro e não o contrário, deixando assim, nosso domínio realmente isolado.
 
Ao final esse seria nosso fluxo correto:
Lado esquerdo -> Centro <- Ioc- Lado Direito
 
Pontos Positivos
Como pontos positivos de utilizar está arquitetura podemos listar os seguintes:
· Solução Independente de Serviços Externos
· Possível adiar algumas decisões técnicas
· Criação e substituição de adaptadores
· Facilidade em testar a aplicação.
· Facilidade na troca de tecnologias.
 
Pontos negativos
 Como nem tudo são flores, temos também alguns pontos negativos no uso da arquitetura hexagonal, sendo eles:
· Complexidade Extra (construção de mais camadas)
· Custo de criação e manutenção.
· Não existe uma orientação sobre organização de código (diretórios, camadas)
 
Conclusão
 
A arquitetura hexagonal é tida como um guia e a partir dela foram sendo criados novos conceitos arquiteturais com informações mais granulares na organização de código (diretórios, camadas), como exemplos temos a arquitetura onion (Onion Arquitecture) por Jeffrey Palermo e a arquitetura limpa (Clear Arquitecture) por Robert C. Martin (Uncle Bob), todas as duas fazem referência ao padrão criado por Alistair Cockburn.
Mesmo que você já opte por seguir a ideia de Jeffrey ou Uncle Bob, eu indico o estudo da arquitetura hexagonal para entender bem o conceito de isolamento do domínio e de comunicação do mesmo com seus respectivos atores, após isso, você verá que ficará mais fácil entender as ideias de outros autores que criaram novos conceitos a partir dessa ideia inicial.
 
Referências
 
· Arquitetura Hexagonal com Java – https://www.udemy.com/course/arquitetura-hexagonal-com-java-1
· Hexagonal architecture – https://alistair.cockburn.us/hexagonal-architecture
· Alistair in the “Hexagone” 1/3 – https://www.youtube.com/playlist?list=PLGl1Jc8ErU1w27y8-7Gdcloy1tHO7NriL