Blog/Artigos · Engenharia
A regra da dependência, ports and adapters de Cockburn, o domínio independente de framework e banco, e o custo de tanta cerimônia.
No Mishkan, uma cortina, a parochet, separava o lugar santo do santo dos santos: ela dividia o que ficava exposto ao movimento do exterior do núcleo mais protegido, onde só entrava o essencial e sob regra estrita. A cortina não isolava por isolar; ela protegia o centro da agitação da borda. Arquitetura de software tem o mesmo problema. A regra de negócio, o núcleo que dá valor, vive cercada de coisas que mudam o tempo todo: o framework da moda, o banco de dados, a interface, o serviço externo. Sem uma cortina, o núcleo se contamina com esses detalhes e passa a mudar junto com eles. Clean Architecture é a parochet do código: a separação que mantém o essencial protegido do que é só detalhe da borda.
A pergunta que Clean Architecture responde é: quando o framework mudar, quando o banco trocar, quando a interface for reescrita, quanto da minha regra de negócio precisa mudar junto? Na arquitetura comum, em camadas onde tudo depende do banco no fundo, a resposta é muito, porque a regra de negócio está amarrada ao detalhe de infraestrutura. Robert C. Martin, no livro Clean Architecture, e Alistair Cockburn, com a arquitetura hexagonal, propuseram a inversão: o núcleo de negócio no centro, sem saber nada do mundo exterior, e os detalhes, banco, framework, interface, nas bordas, dependendo do núcleo, nunca o contrário.
A frase que resume a filosofia é provocadora: o framework é um detalhe, o banco de dados é um detalhe. Não que sejam sem importância, mas que a regra de negócio não deveria depender de qual banco ou qual framework se usa, do mesmo jeito que a lógica de uma loja não depende de a prateleira ser de madeira ou de aço. Quando o núcleo é independente, ele pode ser testado sem subir banco nem servidor, entendido sem conhecer o framework, e preservado quando a borda inteira for substituída. A cortina protege o santo dos santos da agitação constante do pátio exterior.
O princípio único que sustenta tudo é a regra da dependência: o código-fonte só pode depender para dentro, na direção do núcleo. Uma camada externa pode conhecer a interna, mas a interna nunca conhece a externa. A entidade de negócio não importa nada do banco; o caso de uso não sabe se a chamada veio de uma API REST ou de uma fila; o núcleo inteiro poderia ser recompilado sem o framework existir. Toda seta de dependência aponta para o centro, e é isso que mantém o centro imune às mudanças da periferia.
Quando o fluxo de controle precisa ir para fora, o caso de uso precisa gravar no banco, a regra da dependência parece violada: o de dentro precisa chamar o de fora. A solução é a inversão de dependência do SOLID, aqui elevada a princípio arquitetural. O caso de uso define uma interface, uma porta, dizendo preciso salvar isto, e o adaptador de banco, na borda, implementa essa interface. Assim o fluxo de controle vai para fora, mas a dependência de código continua apontando para dentro: a borda depende da porta que o núcleo definiu. É a mesma cortina, com uma passagem controlada, por onde o essencial atravessa sem que a agitação exterior invada o centro.
O fluxo de controle vai para fora, mas a dependência de código continua apontando para dentro. É a inversão de dependência do SOLID elevada a princípio arquitetural.
Alistair Cockburn deu a essa ideia o nome mais concreto: ports and adapters, a arquitetura hexagonal. O núcleo é desenhado como um hexágono, e cada lado é uma porta, um ponto de entrada ou saída definido pelo núcleo em seus próprios termos. Do lado de fora, adaptadores plugam nessas portas para conectar o núcleo ao mundo real. Há dois tipos: os adaptadores que dirigem o núcleo, que iniciam a ação, um controller web, um consumidor de fila, um teste; e os que são dirigidos pelo núcleo, que o núcleo aciona, um repositório de banco, um cliente de serviço externo.
A beleza do modelo é a simetria e a trocabilidade. O mesmo núcleo pode ser dirigido por uma API REST hoje e por uma fila amanhã, sem mudar, porque ambos plugam na mesma porta de entrada. O mesmo caso de uso pode gravar em Postgres em produção e em memória no teste, porque ambos implementam a mesma porta de saída. É isso que torna o núcleo testável de forma trivial: no teste, os adaptadores reais são substituídos por dublês que plugam nas mesmas portas, e a regra de negócio é exercitada sozinha, rápido, sem infraestrutura. O hexágono não tem seis lados por regra; o número é irrelevante. O que importa é a ideia: o núcleo define as portas, o mundo se pluga por adaptadores, e a cortina entre os dois é onde a substituição acontece.
Clean Architecture não é grátis, e vender que é faz mal. A cortina cobra cerimônia: interfaces a mais, camadas de tradução, objetos que só existem para atravessar fronteiras, mais arquivos e mais indireção para uma mesma funcionalidade. Num sistema pequeno, com regra de negócio simples e pouca probabilidade de trocar de banco ou framework, essa cerimônia toda é peso morto: você paga o custo da proteção sem colher o benefício, porque a agitação da qual a cortina protege nunca vem. Aplicar Clean Architecture num CRUD trivial é construir um santo dos santos para guardar um caderno de recados.
O benefício aparece onde a regra de negócio é rica e duradoura, e a borda é volátil ou incerta. Sistema com lógica de negócio complexa que vai viver anos, atravessando várias trocas de framework e talvez de banco, é onde a cortina se paga: o núcleo valioso sobrevive intacto a cada troca da periferia, e continua testável e compreensível enquanto a moda tecnológica muda ao redor. A decisão, como quase tudo em engenharia, é de proporção: quanto mais valiosa e longeva a regra de negócio, e quanto mais volátil a borda, mais a cortina vale o custo. O erro dos dois lados é simétrico: nenhuma separação num sistema complexo condena o núcleo a apodrecer junto com a borda; separação total num sistema trivial afoga uma ideia simples em cerimônia.
A relação com arquitetura limpa amadurece do emaranhado ao julgamento de proporção. No começo tudo depende de tudo, a regra de negócio grudada ao banco e ao framework. Depois vem a descoberta empolgada, aplicando Clean Architecture em tudo, inclusive no que não precisa, a fase da cerimônia à toa. No meio vem a separação seletiva, protegendo o núcleo valioso. No topo é o julgamento maduro: quanta cortina cada sistema merece, do isolamento mínimo ao hexágono completo, conforme o valor do núcleo e a volatilidade da borda. Cada degrau troca o dogma pela adequação.
Clean Architecture é onde SOLID vira arquitetura: a inversão de dependência, que no SOLID é um princípio de classe, aqui organiza o sistema inteiro. E é a moldura que o Domain-Driven Design preenche: a Clean Architecture dá as camadas e a regra da dependência, o DDD dá o que colocar no núcleo, o modelo de domínio rico. As duas juntas formam a espinha da arquitetura de aplicações de negócio complexas. Mas a cortina é meio, não fim: ela existe para que o essencial seja protegido, testável e durável, e num sistema onde não há essencial rico a proteger, a cortina mais atrapalha que ajuda. Saber quando erguer o santo dos santos, e quando um cômodo simples basta, é a marca do arquiteto que serve ao problema, e não à moda.
Clean Architecture é a parochet do código: a cortina que separa o núcleo de negócio, valioso e estável, do que é só detalhe volátil da borda, o framework, o banco, a interface. A regra da dependência mantém todas as setas apontando para dentro, ports and adapters dão a forma concreta, e o núcleo fica testável e imune à troca da periferia. Mas a cortina cobra cerimônia, e ela só se paga onde há um núcleo rico e longevo a proteger de uma borda volátil. A IA guarda a regra da dependência e gera os adaptadores. Saber quanta cortina cada sistema merece, porém, continua sendo julgamento de proporção de quem arquiteta.
Gerente de Operações, Tecnologia e Infraestrutura (SRE) numa central de registros. Trabalho com tecnologia desde 2009 e com cibersegurança em tempo integral desde 2015, em infraestrutura crítica, fintech e banking. Escrevo sobre o que eu opero: confiabilidade, segurança, governança e IA que passa por gate antes de chegar em produção.
Engenhariaעֲבוֹדָה
Código sem princípio apodrece: cada mudança quebra três coisas e o medo trava a evolução. SOLID são cinco princípios que mantêm o código maleável, e o coração de todos é o mesmo: cada peça com uma responsabilidade só, uma razão só para mudar.
Engenhariaשֵׁמוֹת
A maior distância num projeto não é técnica, é entre o que o negócio diz e o que o código faz. DDD fecha essa distância nomeando o domínio com precisão: uma linguagem única entre quem entende o negócio e quem escreve o código, e fronteiras claras entre contextos onde a mesma palavra significa coisas diferentes.
