Marcio Cunha

Modelagem de Domínios Complexos com Arquitetura Hexagonal em Sistemas Legados

Descubra estratégias práticas para desacoplar regras de negócio de bancos de dados legados utilizando a arquitetura hexagonal, isolando o código antigo e viabilizando novas funcionalidades com segurança.

Marcio Cunha•4 min
Também disponível em:EnglishEspañol
Resumo
  • Sistemas legados acumulam regras de negócio acopladas ao banco de dados e frameworks antigos.
  • A arquitetura hexagonal isola o núcleo da aplicação por meio de portas e adaptadores.
  • O reator de dependências é invertido para que o banco e a interface sirvam ao domínio.
  • A introdução gradual de testes unitários protege as regras essenciais contra efeitos colaterais.
  • O isolamento permite reescrever partes do sistema sem interromper a operação atual.

O Desafio dos Sistemas Legados Acoplados

Trabalhar com sistemas legados costuma ser um exercício de paciência e arqueologia digital. Muitas vezes, a lógica de negócio está espalhada por procedures em bancos de dados, controladores de frameworks obsoletos e arquivos de configuração esquecidos. Na prática, isso significa que alterar uma simples regra de cálculo de impostos pode quebrar o cadastro de clientes ou corromper o faturamento. O código perdeu a coesão e o acoplamento excessivo impede qualquer evolução rápida ou segura da aplicação.

Quando o domínio de negócio é complexo e o software é antigo, o risco de regressão paralisa os times de engenharia. Mudar qualquer linha de código parece caminhar em um campo minado. Para resolver esse problema sem precisar reescrever o sistema inteiro do zero, precisamos mudar a forma como encaramos as dependências técnicas. É aqui que entra a arquitetura hexagonal, uma abordagem de design de software que protege o coração da aplicação contra o caos externo.

O Conceito de Arquitetura Hexagonal na Prática

A arquitetura hexagonal, também conhecida como ports and adapters (portas e adaptadores), foi criada para isolar o núcleo da aplicação — onde residem as regras de negócio puras — dos detalhes tecnológicos externos, como bancos de dados, APIs de terceiros e interfaces gráficas. Na prática, imagine uma tomada elétrica e o seu aparelho. A tomada possui um formato padrão (porta) e qualquer cabo compatível (adaptador) pode fornecer energia sem que o aparelho precise saber como a eletricidade é gerada na usina.

No código, o núcleo da aplicação define interfaces chamadas portas, que determinam o que a aplicação precisa fazer ou receber. Os adaptadores implementam essas portas para conversar com o mundo exterior. Se o banco de dados mudar de MySQL para PostgreSQL, ou se a interface web migrar para uma API REST, o núcleo de negócio permanece absolutamente intocado. Essa inversão protege o investimento de engenharia e garante que o coração do software sobreviva à obsolescência tecnológica.

Mapeando o Domínio em Meio ao Caos Tecnológico

O primeiro passo para aplicar a arquitetura hexagonal em um legado não é mexer no código imediatamente, mas sim entender as fronteiras do domínio. Domínio complexo significa que existem regras de negócio cheias de nuances, exceções e fluxos condicionais que pertencem estritamente ao negócio, e não à tecnologia. Na prática, precisamos separar o que a empresa faz (como calcular descontos progressivos) de como a empresa armazena isso (se numa tabela SQL ou em um arquivo CSV).

Durante essa fase de mapeamento, é comum encontrar regras escondidas dentro de validações de tela ou disparadores de banco de dados. O trabalho do engenheiro é extrair essa lógica e trazê-la para classes puras de linguagem, livres de frameworks. Esse núcleo isolado passa a ser a única fonte da verdade para o comportamento do sistema. Quando o modelo reflete fielmente o negócio, as manutenções futuras deixam de ser adivinhações e passam a ser evoluções planejadas.

Implementando Portas e Adaptadores Gradualmente

Reescrever um sistema legado de uma vez só é uma receita clássica para o fracasso. A abordagem mais segura na arquitetura hexagonal é a criação de um bolsão isolado dentro do próprio monólito. Começamos identificando uma funcionalidade crítica ou um novo requisito que precise ser implementado. Criamos a camada de domínio e as portas necessárias para essa funcionalidade específica, mantendo o restante do sistema legado funcionando como sempre.

Para integrar o código novo ao sistema antigo, criamos adaptadores que traduzem as chamadas legadas para o formato esperado pelas novas portas. Veja um exemplo conceitual de uma porta de repositório em Java puro, isolada de detalhes de persistência:

public interface UsuarioRepositoryPort {
void salvar(Usuario usuario);
Optional<Usuario> buscarPorId(Long id);
}

O adaptador correspondente que conversa com o banco legado implementa essa interface, fazendo a ponte sem contaminar o núcleo da aplicação com bibliotecas específicas de banco de dados ou SQL nativo.

Benefícios Operacionais e Redução de Riscos

Adotar a arquitetura hexagonal em sistemas legados traz ganhos imediatos na testabilidade do software. Como o domínio de negócios está completamente desacoplado de frameworks e bancos de dados, podemos escrever testes unitários extremamente rápidos utilizando objetos simulados, os chamados mocks. Na prática, rodar a suíte de testes de negócio deixa de levar horas para durar poucos segundos, aumentando drasticamente a confiança da equipe.

Outro benefício crucial é a clareza arquitetural. Novos desenvolvedores que entram no projeto não precisam aprender todas as excentricidades do framework antigo para entender o que o software faz; basta lerem o código do núcleo de domínio. O acoplamento diminui, a legibilidade aumenta e a empresa ganha a capacidade de evoluir partes do sistema de forma independente, reduzindo drasticamente o custo de manutenção a longo prazo.

Considerações Finais sobre a Modernização Progressiva

Modernizar sistemas legados com arquitetura hexagonal não é um evento único, mas sim uma jornada contínua de refinamento estrutural. A aplicação gradual de portas e adaptadores permite que o negócio continue gerando valor enquanto a engenharia limpa a dívida técnica nos bastidores. O segredo está em respeitar as fronteiras do domínio, isolando o código antigo e garantindo que cada nova funcionalidade nasça limpa e desacoplada.

Com paciência, disciplina e foco na modelagem correta, é possível transformar um monólito frágil em um sistema resiliente e preparado para o futuro. A arquitetura hexagonal prova que não é preciso destruir o passado para construir um código melhor; basta saber organizá-lo ao redor do que realmente importa para o negócio.