DEV Community

Alberto Luiz Souza
Alberto Luiz Souza

Posted on

Arquitetura Hexagonal e Clean Architecture: Entendendo as Similaridades

Disclaimer

Este texto foi inicialmente concebido pela IA Generativa em função da transcrição do episódio do nosso canal, Dev Eficiente. O episódio completo pode ser visto no canal.

Introdução

A arquitetura de software é um tema que gera muitas discussões e, entre as abordagens mais populares, estão a Arquitetura Hexagonal e a Clean Architecture. Embora os nomes possam sugerir diferenças significativas, a verdade é que ambas compartilham os mesmos princípios e objetivos. Neste post, vamos explorar essas duas arquiteturas e mostrar como elas, na prática, buscam resolver os mesmos problemas.

O Problema Central: Blindar o Domínio

Tanto a Arquitetura Hexagonal quanto a Clean Architecture têm como principal objetivo blindar o núcleo do software. O núcleo, também chamado de domínio, é a parte mais importante do sistema, onde residem as regras de negócio. A ideia é proteger esse núcleo de mudanças que possam ocorrer nas camadas externas, como alterações em frameworks, bibliotecas ou protocolos de entrada de dados.

Imagine que você está utilizando um framework para receber dados via HTTP. Se esse framework for atualizado e mudar a forma como os dados são recebidos, você não quer que isso afete diretamente o núcleo do seu sistema. Para evitar esse tipo de acoplamento, tanto a Arquitetura Hexagonal quanto a Clean Architecture propõem a criação de abstrações que isolam o núcleo das camadas externas.

Ports and Adapters vs. Use Cases

Na Arquitetura Hexagonal, o conceito de Ports and Adapters é central. As ports (portas) são as interfaces que definem como o núcleo do sistema se comunica com o mundo externo. Já os adapters (adaptadores) são responsáveis por adaptar os dados recebidos de diferentes fontes (como HTTP, GRPC, etc.) para o formato esperado pelas portas.

Na Clean Architecture, o conceito equivalente às portas são os use cases (casos de uso). Um caso de uso representa uma funcionalidade específica do sistema, como o cadastro de um usuário ou a geração de um relatório. Assim como as portas, os casos de uso definem como o núcleo do sistema interage com o mundo externo.

Embora os nomes sejam diferentes, o objetivo é o mesmo: isolar o núcleo do sistema e garantir que ele não seja afetado por mudanças nas camadas externas.

Inversão de Dependência

Outro conceito importante em ambas as arquiteturas é a inversão de dependência. A ideia aqui é que o núcleo do sistema nunca deve depender diretamente de componentes externos, como bancos de dados ou serviços de mensageria. Em vez disso, o núcleo define interfaces que são implementadas pelas camadas externas.

Por exemplo, se o seu sistema precisa gravar dados em um banco de dados, você não deve acoplar o núcleo diretamente ao banco. Em vez disso, você cria uma interface que define os métodos necessários para gravar os dados, e essa interface é implementada por um adaptador que se comunica com o banco de dados. Dessa forma, se você decidir trocar o banco de dados no futuro, o núcleo do sistema não será afetado.

Adaptadores Primários e Secundários

Na Arquitetura Hexagonal, os adaptadores são divididos em dois tipos: primários e secundários. Os adaptadores primários são aqueles que recebem dados do mundo externo e os enviam para o núcleo do sistema. Já os adaptadores secundários são aqueles que o núcleo utiliza para se comunicar com o mundo externo, como ao gravar dados em um banco de dados ou enviar uma mensagem para uma fila.

Na Clean Architecture, essa divisão também existe, embora os termos possam variar. O importante é entender que, em ambas as arquiteturas, o núcleo do sistema nunca se comunica diretamente com o mundo externo. Sempre há uma camada de abstração que garante que o núcleo permaneça isolado e protegido.

Conclusão

Tanto a Arquitetura Hexagonal quanto a Clean Architecture compartilham os mesmos princípios e objetivos. Ambas buscam blindar o núcleo do sistema, garantindo que ele não seja afetado por mudanças nas camadas externas. Embora os nomes e alguns detalhes possam variar, o conceito central é o mesmo: isolar o domínio e garantir que o sistema seja flexível e fácil de manter.

E lembre-se: o mais importante não é seguir à risca os nomes ou os detalhes de cada arquitetura, mas sim entender os princípios por trás delas e aplicá-los de forma que faça sentido para o seu projeto.

Se você quiser se aprofundar mais nesse tema, recomendo explorar o conteúdo da Jornada Dev + Eficiente, onde há um módulo completo sobre arquitetura em camadas, com exercícios práticos para você aplicar no seu dia a dia.

Deixe seu comentário abaixo, seja ele positivo ou construtivo, e terei o maior prazer em responder. Até a próxima!

Top comments (0)