Arquitetura Hexagonal em Java: Como Blindar sua Aplicação das Mudanças Externas

 


O conceito de Arquitetura Hexagonal foi proposto por Alistair Cockburn, ainda nos anos 90, em um artigo publicado na primeira wiki da internet, a WikiWikiWeb famosa por reunir conteúdos sobre Engenharia de Software.

Os objetivos dessa arquitetura se alinham bastante com os princípios da Arquitetura Limpa: promover reutilização de código, alta coesão, baixo acoplamento, independência tecnológica e testabilidade. Em resumo, é uma forma de construir sistemas preparados para mudanças e longevidade.

 

Dois Mundos Bem Separados

A Arquitetura Hexagonal propõe que as classes do sistema sejam divididas em dois grandes grupos:

  • Classes de Domínio: onde vive a lógica de negócio pura.

  • Classes de Infraestrutura: que lidam com tecnologias específicas, como bancos de dados, frameworks, APIs externas e interfaces de usuário.

A regra de ouro é simples: as classes de domínio nunca devem depender das classes de infraestrutura. Essa separação garante que a lógica central do sistema continue estável, mesmo quando mudamos tecnologias ao redor dela.

Imagine poder trocar seu banco de dados, a interface REST ou até adicionar uma versão mobile, sem precisar tocar nas regras de negócio. Essa é a promessa da Arquitetura Hexagonal.

 

O Papel Dos Adaptadores

Essa separação é mediada por adaptadores — componentes que conectam o mundo externo com o domínio usando o padrão de projeto Adapter. Eles transformam chamadas e dados externos em formatos que o domínio entende (e vice-versa).

Visualmente, costuma-se representar isso como dois hexágonos concêntricos:

  • No centro: as classes de domínio (ou de negócio).

  • Em volta: os adaptadores.

  • Fora dos hexágonos: as tecnologias e sistemas externos, como bancos de dados, frameworks e interfaces.

 

O Problema do Acoplamento

Na maioria das aplicações Java (especialmente com frameworks como Spring), é comum ver classes de negócio diretamente ligadas ao JPA, controllers REST e objetos da infraestrutura.

Isso traz alguns problemas:

  • Dificuldade para testar regras de negócio isoladamente.

  • Trocar o banco de dados ou protocolo (REST → gRPC) exige reescrever muita coisa.

  • Baixa coesão e alta complexidade em manutenção.

     

Conceitos Fundamentais da Arquitetura Hexagonal

A Arquitetura Hexagonal parte da ideia de que o núcleo do sistema deve ser imutável e puro. Isso é feito com três blocos principais:

1. Domínio (ou Core)

  • Contém entidades, serviços de negócio e casos de uso.

  • Não conhece nenhum framework.

2. Portas (Ports)

  • Interfaces que representam entradas (casos de uso) e saídas (repositórios, serviços externos).

  • São definidos no domínio, mas implementados fora dele.

3. Adaptadores (Adapters)

  • Implementam as portas.

  • Interagem com frameworks e tecnologia: controladores HTTP, JPA, APIs externas, etc.

     

Para ilustrar esses conceitos, você pode conferir um projeto real que desenvolvi seguindo a Arquitetura Hexagonal em Java. Veja o repositório no GitHub:


 https://github.com/GabrielFCarrijo/Hexagonal_Architecture

 

Vantagens Reais da Arquitetura Hexagonal

  • Testes fáceis: é possível testar toda lógica de negócio com mocks das portas.

  • Tecnologia plugável: pode trocar REST por gRPC, JPA por Mongo, com impacto mínimo.

  • Organização clara: responsabilidades bem definidas.

  • Escalabilidade técnica: múltiplas interfaces (ex: REST, CLI, mobile) usando o mesmo domínio.

 

 Com isso conseguimos ver que a Arquitetura Hexagonal é uma estratégia poderosa para quem quer escrever código limpo, testável e preparado para o futuro. Em Java, ela exige disciplina na separação de camadas e um bom entendimento de interfaces, mas os ganhos são enormes.



Back-end Developer Java | Spring Boot | Quarkus | Microservices | SQL & NOSQL | SOLID | Design Patterns


Comments

Popular posts from this blog

Spring VS Micronaut VS Quarkus

Spring + Redis: Como melhorar sua aplicação com caching

Java + Kafka, Como essa parceria fucniona ?