Esta semana, me deparei com críticas à arquitetura Hexagonal (Ports and Adapters) fundamentadas na suposição equivocada de que seu uso está condicionado à aplicação de Domain-Driven Design (DDD). Como se fosse um privilégio reservado apenas a sistemas que alcançaram um suposto “grau de maturidade arquitetural”. Essa ideia, infelizmente, afasta bons profissionais de algumas das abordagens mais poderosas para evolutividade e manutenção de software.

Separar seu núcleo de negócio das camadas tecnológicas não é sobre a adoção de DDD, embora possa tirar proveito de…

É sobre clareza, fluidez e inteligência de arquitetura. Ao isolar o core da aplicação — e uso “core” propositalmente para não usar o termo “domínio” — você está tomando uma decisão consciente de reduzir acoplamento, minimizar a carga cognitiva e facilitar a evolução do sistema.

Hexagonal não é sobre a possibilidade de trocar tecnologias como banco de dados ou frameworks web. É sobre não misturar alhos com bugalhos.

Quando se mantém o coração da aplicação alheio às tecnologias de entrada e saída, cria-se um terreno sólido para sustentação e adaptação futuras. Embora não pareça intuitivo, reduz a complexidade.

Não é sobre DDD, é sobre boas práticas fundamentais

Um equívoco recorrente é presumir que a adoção de uma arquitetura hexagonal ou de serviços agnósticos exige obrigatoriamente a implementação de DDD (Domain-Driven Design). Embora DDD e Hexagonal compartilhem ideais como separação de responsabilidades e foco no domínio de negócio, não há dependência entre eles. A arquitetura hexagonal pode (e deve) ser usada em qualquer cenário que exija organização, desacoplamento e manutenibilidade, independentemente da complexidade ou da presença de um domínio rico.

É totalmente possível — e frequentemente desejável — aplicar uma arquitetura limpa e desacoplada mesmo em sistemas com domínio simples ou centrados em orquestração. Você não precisa de agregados, entidades ricas ou repositórios complexos para justificar a escolha por Port and Adapters ou Agnostic Services.

Basta querer:

• evoluir com liberdade
• testar com confiança
• manter com tranquilidade.

Ao insistir que DDD seja pré-requisito para boas práticas arquiteturais, limitamos seu uso a uma elite de projetos “dignos”.
Isso não apenas uma falácia, como também desincentiva equipes de investir em qualidade desde cedo.
Arquiteturas que promovam a separação clara de responsabilidades são ferramentas universais.
Elas pertencem a todos os projetos que desejam crescer de forma saudável.

Ser manutenível exige esforço

Projetos que começam simples, com APIs REST sincrônicas, muitas vezes evoluem para demandas mais sofisticadas: cache, filas, streams, resiliência, escalabilidade. A transição natural de um fluxo sincrônico para um modelo assíncrono acontece muito antes de se atingir milhões de requisições por segundo. A necessidade de resiliência surge cedo, independente do tamanho do projeto. E é comum que nesses cenários, projetos fortemente acoplados e dependentes da camada web se tornem verdadeiros gargalos para evolução. Refatorar controladores que fazem tudo, reorganizar lógicas de negócio espalhadas entre middlewares, services e endpoints passa a ser uma tarefa onerosa e arriscada, dificultando a introdução de novas portas de entrada como filas ou streams.

E é justamente aqui que a arquitetura mostra mais uma vez seu valor. Se o seu core está amarrado diretamente à camada web, a introdução de novos mecanismos de comunicação exige refatoração pesada, arriscada e cara. Agora, se esse core for agnóstico — desacoplado, limpo e bem definido — novas portas podem ser conectadas com mínimo atrito, com o mínimo esforço.

Projetos bem pensados não são sobre previsão do futuro, mas sobre preparação inteligente para o inesperado. Como uma bicicleta com rodas encaixadas, não soldadas: você não sabe se vai precisar trocá-las, mas se precisar, não precisa descartar a bicicleta inteira.

E se você acha que esse é o argumento central, calma! O melhor está por vir.

Arquitetura não é luxo, é inteligência

Existe um preconceito comum contra a arquitetura hexagonal, como se fosse um “enlatado complexo” reservado a sistemas elitizados.

A verdade é que por trás do desenho conceitual está um princípio fundamental da engenharia de software: separação clara de responsabilidades.
Não se trata de overengineering, trata-se de manter coesão, facilitar testes, e principalmente, tornar a manutenção mais leve e o crescimento mais natural.

Antes de rejeitar uma abordagem por parecer sofisticada demais, reflita:

• quantas horas você ou seu time gastam para adaptar o sistema a uma nova necessidade?
• Quantos efeitos colaterais emergem de mudanças aparentemente simples?

E se a solução não for mais complexidade, mas mais organização e inteligência na separação de responsabilidades?

Agnostic Services criou uma nova era na forma como modelo software

Desde 2006, utilizo o conceito de Agnostic Services como base para construção de sistemas e posso afirmar, sem exageros, que essa decisão transformou profundamente minha maneira como enxergo, desenvolvo e entrego software.

A ideia central é simples: construir serviços que não conhecem o meio de entrada e não dependem da camada de transporte. São componentes de negócio autocontidos, testáveis, reaproveitáveis, que podem ser invocados por qualquer “porta”: seja uma API REST, uma fila RabbitMQ, um worker em background, uma requisição gRPC ou um job schedulado. Esse modelo traz uma liberdade arquitetural imensa e elimina a fricção para expansão.

Ao adotar Agnostic Services, passei a pensar e evoluir sistemas de forma mais estratégica. A entrega de novas features tornou-se mais fluida, e a capacidade de reagir às demandas se multiplicou, além de reduzir drasticamente a quantidade de bugs introduzidos por mudanças estruturais. Os times com quem trabalhei reclamaram muito, e reclamam até hoje, mas conseguiram escalar (aumentar quantidade de features) de suas soluções com menos dor e mais confiança.

Essa escolha, feita há quase duas décadas, moldou toda a minha abordagem profissional. E se hoje consigo construir soluções resilientes, adaptáveis e sustentáveis, muito disso se deve a essa base: serviços agnósticos e foco em separação real de responsabilidades.

Hexagonal e Agnostic Services: convergência de princípios

Ao observar com atenção, percebemos que a arquitetura Hexagonal e os Agnostic Services compartilham a mesma essência: manter o núcleo de negócio isolado das preocupações externas. Ambas as abordagens valorizam a independência do core em relação às tecnologias de transporte, infraestrutura ou comunicação.

A principal diferença está na perspectiva e na abrangência de suas propostas.

A arquitetura Hexagonal define uma estrutura arquitetural clara, e se aprofunda nos conceitos de portas e adaptadores delimitando as interações entre o mundo externo e o sistema. Enquanto Agnostic Services refere-se a serviços projetados para serem completamente independentes do meio de transporte, infraestrutura ou plataforma.

Enquanto Hexagonal fala de todo o isolamento completo do core, Agnostic Services se limita à preocupação em não contaminar os serviços com especificidades de tecnologias de exposição e seus protocolos, como Web API, HTTP, REST, gRPC, AMQP, RESP. O transporte é tratado como um detalhe de configuração externa.

Se por um lado a arquitetura Hexagonal define os limites do sistema, tanto em portas, quanto em adapters e como as integrações se conectam a ele, os Agnostic Services se preocupam apenas com as portas e a pureza e coesão das unidades internas.

Portanto, se você já adota arquitetura hexagonal, é provável que já faça uso de Agnostic Services, mas caso não, pode ser um passo menor, e talvez o próximo passo natural. E se você já pratica Agnostic Services, a arquitetura Hexagonal oferece um arcabouço que amplifica ainda mais seus benefícios.

Mas por que citar Agnostic Services em uma publicação cujo foco é Hexagonal e DDD?

A similaridade entre ambas as abordagens é enorme, partem dos mesmos princípios e são formas mais simples ou mais complexas de lidar com o mesmo problema: acoplamento entre chamada de negócio e tecnologias diversas. Esse acoplamento torna, muitas vezes, o negócio imperceptível dentro de fluxos basicamente tecnológicos.

A mistura entre regras de negócio a burocracia de componentes tecnológicos multiplicam a complexidade, dificultando a manutenção e aumenta principalmente a probabilidade de surgirem erros durante manutenções.

E aqui está meu ponto sobre o assunto: Embora tenha praticado pouco Hexagonal, pratico Agnostic Services há ao menos 18 anos, e suas semelhanças me permitem transplantar ideias de um universo para o outro, obviamente mantendo-me atento às diferenças.

Uma escolha que define o futuro

Arquiteturas que separam o [CORE, DOMÍNIO, NEGÓCIO] de tecnologias específicas, simplificam a evolução e geram diferencial na hora de manter, seja para mudar ou evoluir.

Adotar uma arquitetura que promova um core agnóstico é metade do caminho para evitarmos que um projeto seja condenado a ser reescrito na hora de evoluir sua a arquitetura.

Você encontrará essas pistas em todos os meus projetos desde 2006, e o que ganhei com essa abordagem:

• Desafetos
• Stress
• Perda de Cabelo
• mas também:
  • Projetos mais bem delimitados.
  • Errar feio, é algo burocrático (precisa fazer bastante força).
  • Decisões difíceis, que demandariam muito esforço, passam a ser triviais.

Evoluções e restruturações de projetos sempre foi desafiador para clientes e consultores, entretanto em todos os casos, segui abordagens minimalistas que visavam consumir o mínimo de infraestrutura, para entregar profissionalismo aos projetos restruturados.

Meu PlayBook de refatoração conta com:

• observabilidade (comecei com ELK Stack, mas hoje privilegio LGTM)
• Cache (redis)
• Filas (rabbitmq)

esses elementos estão no topo das primeiras necessidades de todos os projetos que já fui chamado para restruturar. E não tenho históricos de fracassos ou grandes desafios em projetos de restruturação com esse PlayBook.

Mas o grande problema é que, na maior parte das vezes, aplicações centradas na web, em especial em Web Apis ou Web Apps, sem um core agnóstico, demandam muita reescrita e muita rearquitetura para permitir a adoção de filas, ou o uso de outros protocolos. O acoplamento cobra um preço muito alto.

Quando escolhi promover Agnostic Services à parte da baseline de arquitetura para meus projetos, (ou seja, exceto caso seja algo muito exótico (ainda não aconteceu), ele estará presente na arquitetura de qualquer projeto meu), ganhei projetos que ofereciam maior clareza, cada coisa no seu devido lugar.

A capacidade de reagir às necessidades cotidianas aumentou, e agora lidar com incertezas deixou de ser um grande problema estrutural. Mover fluxos que precisam de mais resiliência do que o oferecido pelo HTTP, saiu de uma escala de semanas ou meses, para uma escala de horas ou dias. Tudo porque ficou mais simples.

A separação rígida melhorou a testabilidade, aumentou o reaproveitamento de componentes, o que fortalece DRY, e reduziu a dificuldade de manter os projetos.

Mas o maior benefício, do ponto de vista de arquitetura, está em não precisar fazer falsas suposições hipotéticas. Não precisar chutar números com base em predições mediúnicas geradas a partir de números inventados.

Agora eu posso dizer um belo e singelo: Não sei e não me importa.
Porque agora eu posso dizer: Independente do que venha, reagimos rápido e antes que se torne um problema de fato!

Essa abordagem me permite reduzir a importância da decisão sobre filas ou http síncrono. No final das contas, “tanto faz” e, portanto, entrega a flexibilidade que eu preciso para não precisar tomar essa decisão e morrer abraçado a ela.

Muitas vezes só queremos não correr muito risco, e não precisar tomar decisões das quais não temos informações suficientes para uma previsão informada, só suposições com alta margem de erro.

Agnostic Services tem sido meu “seguro” contra incertezas, previsões erradas e suposições equivocadas. E Hexagonal Architecture/Ports and Adapters, pode herdar o mesmo status nos seus projetos, independente da adoção de DDD ou não.