O que é arquitetura hexagonal?

Neste bate-papo, saiba como esse padrão de arquitetura pode otimizar estratégias de Microsserviços. Os arquitetos da Sensedia Aldinei Simões e Carlos Pinheiro trazem uma visão geral sobre a arquitetura hexagonal, mostram em quais situações sua aplicação faz mais sentido e destacam as melhores práticas para aproveitar seus benefícios. 

Você também pode acompanhar o bate-papo no formato de áudio, é só dar o play!

Podem começar trazendo uma visão geral da arquitetura hexagonal? ‍

Aldinei: A arquitetura hexagonal surgiu nos anos 1990 e veio para organizar o processo de desenvolvimento e torná-lo mais maleável - uma estrutura de sistemas menos bagunçada, com um acoplamento pequeno e uma coesão grande. A ideia é separar a classe de domínio, onde ficarão as regras de negócios das estruturas externas que vão acessá-las, das interfaces, da infraestrutura, das conexões. 

Você pode questionar: se estou dividindo em camadas, por que é chamada de hexagonal? Porque cada lado do hexágono, no desenho, é destinado a um motivo de existir para acessar a classe de domínio. Seria uma maneira de acessar a regra de negócios. Cada lado é um motivo específico: uma forma de acessar web, uma forma de acessar mobile, uma forma de acessar aplicativos em qualquer outro lugar que eles pudessem existir. Essa é a ideia da hexagonal, mas ela é composta como se fossem camadas também.

É exatamente fazer essa separação, essa estruturação para que possamos ter qualquer modelo de interface acessando a regra de negócio sem nenhum acoplamento ou obrigação de uma coisa estar ligada à outra. Isso facilita muito a manutenção no futuro, sem a dependência de nenhuma tecnologia. Por exemplo, não é preciso desenvolver especificamente para web - é possível ter um sistema desenvolvido para qualquer interface que quiser acessá-lo. Podemos trabalhar com qualquer estrutura porque a regra de negócio está sozinha, esperando ser acessada e acessando o que precisa. Para ela, tanto faz a parte de receber requisições ou pedir requisições para o mundo externo. Como ela faz isso? Baseada em um modelo que chamamos de Adapters e Ports. 

Na arquitetura hexagonal, existem dois modelos de portas: portas de entrada e portas de saída (ports-in e ports-out). E o que seriam esses ports? Se fizermos uma relação com Java, as portas precisam ser agnósticas do processo e trazer uma maneira de você acessar várias interfaces, vários modelos de entrada e de saída. Como fazemos isso em Java, .NET ou qualquer linguagem orientada a objetos? Criando interfaces, que seriam as portas. Interfaces criam os modelos de conexão com a classe de domínio, que são as regras de negócio. Então, você cria adapters para implementar essas interfaces, que são nossas classes de implementação, que seriam nossos adapters que fariam a conexão com o mundo externo para fazer a comunicação com seus domínios. Essa é uma ideia bem clara de como isso pode funcionar. 

Quais são os cenários mais apropriados para a aplicação da arquitetura hexagonal e o que justifica a escolha desse modelo? ‍

Carlos: O principal cenário é para criar um sistema desacoplado e cada microsserviço ser um componente com ciclo de vida completamente independente. A escolha pela hexagonal traz flexibilidade para expor a funcionalidade, a capacidade. Por exemplo, recuperar dados do cliente: há uma porta na qual um ator principal - que pode ser um sistema ou qualquer outro usuário - vai se comunicar através de um adapter e acessar essa porta, que é uma API, no sentido puro mesmo. Então, vai solicitar os dados do cliente, e essa porta vai responder para o adapter com esses dados. 

É interessante que ela traz um entendimento de desacoplamento quando vemos que uma porta pode ser exposta como REST no componente, no microsserviço mesmo. Então ela é uma API, que por acaso tem formato REST, e a API que a gente expõe, por exemplo, no nosso gateway, na verdade ela é um adapter. Há essa separação e esse adapter pode só estar fazendo um proxy, uma chamada direta ou pode eventualmente estar fazendo alguma transformação para que o front-end, uma aplicação, passe os dados, que a gente adapta, transforma para passar na porta, que é única. Ele vai fornecer uma única porta para responder o cliente a diversos adapters, seja uma aplicação web, uma aplicação mobile, uma API no API Gateway, um CLI. Ela traz uma arquitetura bem flexível, não só no sentido do microsserviço, de poder ser publicado e rodar independente de outros componentes, mas da própria arquitetura do microsserviço ter essa flexibilidade de fornecer essa capacidade para vários outros consumidores, atores principais de um caso.

Aldinei: A ideia da arquitetura hexagonal é ser mais livre, desacoplar o máximo possível, mas estar bem coesa. É isolar totalmente a parte de domínio. A arquitetura de classe é independente da arquitetura de domínio, e os domínios não devem e não vão conhecer a estrutura de classe externa. Elas ficam totalmente livres para você adaptar com qualquer outra estrutura externa que existir. Essa é uma das grandes vantagens da arquitetura hexagonal: justamente deixar o domínio totalmente implementável para qualquer área externa que aparecer, seja ela um gateway, um aplicativo, uma área web. Ela fica totalmente livre e independente de qualquer interface que chamará ou de qualquer modelo de chamada que terá.

Em relação às melhores práticas, o que os desenvolvedores e arquitetos devem e não devem fazer ao utilizar a arquitetura hexagonal?‍

Carlos: A arquitetura é montada para isolar a lógica do domínio de negócio, o que o componente, o microsserviço faz. Ele deveria fazer aquela coisa muito bem feita e para isso aquele domínio estar bem projetado, isolado e coeso. Usar uma abordagem orientada ao domínio é uma boa prática. 

É bem comum as pessoas simplesmente fazerem o microsserviço sob demanda de uma integração específica. Principalmente nós, que trabalhamos com integração, para integrar o sistema B com o sistema A, fazemos um microsserviço no meio. Na prática, estamos só fazendo um microsserviço que está tratando um domínio que às vezes nem é dele ou temos 10 microsserviços tratando aquele domínio, que está expondo uma única porta para um único adapter nos dois lados, seja no lado do ator principal ou no lado do ator secundário.

O ator secundário é o que responde, ou seja, tem um sistema que é isolado do ator principal que executa alguma tarefa a pedido do ator principal e dá o retorno. Ao termos essa percepção do domínio, conseguimos gerar microsserviços, dentro da arquitetura hexagonal, bem mais coesos.

Outra coisa é conhecer bem os padrões. O microsserviço, na arquitetura hexagonal, vai se comunicar e fornecer funcionalidades através das portas que serão consumidas por meio do adapter pelo usuário, o ator principal, e ele vai integrar também o ator secundário, que é quem fornecerá, por exemplo, uma resposta para aquela capacidade que está sendo requisitada.

É fundamental conhecer esses padrões de integração desses adapters - não é só expor uma API. Confundem bastante a arquitetura hexagonal e acham que a API que está expondo é uma porta ou só expõe uma interface REST e está tudo certo. Se não há um adapter para consumir, aquilo já começa a fraquejar. E, eventualmente, pensar em como fazer o adapter para a integração assíncrona, com fila. O microsserviço, o domínio, não deveria conhecer a fila. Ele fornece a capacidade e a fila é uma abstração para ele. Será responsabilidade do adapter dizer como será. E evitar misturar as camadas. Não é só expor, por exemplo, uma API REST, fazer o port e deixar o resto misturado.

Aldinei: Dois princípios do SOLID que temos no desenvolvimento são importantes para o pessoal se atentar e manter essa coesão da arquitetura hexagonal. 

Um é o princípio da responsabilidade única. No desenvolvimento do Clean Code, a responsabilidade única diz que o domínio pode mudar por um motivo apenas, mais nada. E na arquitetura hexagonal é exatamente isso. Se ele estiver enquadrado nesse um motivo para mudar, já começa a ter uma classe de domínio se enquadrando dentro do que a gente precisa da arquitetura.

E o outro é usar o princípio da inversão de dependência, porque, se você souber como fazer isso, você começa a dizer que o domínio recebe as dependências e não passa a depender de nada. Então, quando ele recebe, está isento de qualquer acoplamento com outras estruturas e camadas. Esses dois princípios são fundamentais para mantermos um isolamento da classe de domínio e fazer com que ela comece a se enquadrar na arquitetura hexagonal.