O'que A Mao Direita Faz A Esquerda Nao Precisa Saber

Entendendo separação de responsabilidades no desenvolvimento web

A expressão o que a mão direita faz a esquerda não precisa saber é usada há anos em fóruns de programação brasileira para descrever um princípio básico de arquitetura de software: separação de responsabilidades. Na prática, significa que cada componente do sistema deve focar apenas no que lhe compete, sem precisar entender os detalhes internos dos outros componentes com os quais se comunica. Isso parece simples até você tentar aplicar em um projeto real. O problema é que, no dia a dia, é muito fácil deixar que a lógica de apresentação vaze para o controlador ou que a camada de negócio conheça a estrutura do banco de dados. E quando isso acontece, qualquer mudança piccola quebra três telas diferentes.

O que a mão direita faz a esquerda não precisa saber na prática

Vamos ao exemplo mais comum: uma aplicação ASP.NET MVC. O controlador recebe um pedido, consulta o repositório, monta o modelo e passa para a view. A view só deve exibir os dados. Ponto. Se você colocar um query SQL dentro do método que monta o modelo na view, já quebrou o princípio. E eu vi muita gente fazer isso porque "era mais rápido". Claro que era mais rápido. Mas na semana seguinte, quando precisou alterar o formato daquela tela, precisou editar o repositório também, e o repositório estava sendo testado por outra tela que funcionava perfeitamente. O mesmo vale para o domínio inverso. A camada de negócio não deve importar referências da camada de apresentação. Eu trabalhei em um projeto onde o service chamava um método estático de uma classe de formatação de tela. Quando migraram de Windows Forms para web, tiveram que refazer todo o service porque ele dependia de controles de interface que não existiam mais. Levou duas semanas de trabalho que poderiam ter sido evitadas com uma interface bem definida.

Como aplicar isso no seu código

A maneira mais direta é definir contratos claros entre as camadas. Use interfaces para tudo que cruza esses limites. O controlador não precisa saber como o repositório busca os dados, só precisa saber que existe um método que retorna o que ele pede. A view não precisa saber de onde vêm os dados, só precisa saber que eles existem. Se você está usando Injeção de Dependência, isso fica mais fácil. Configure os bindings de forma que cada camada receba apenas o que precisa. Evite serviços singleton que conhecem todas as outras camadas. Eu já vi container de DI com mais de cinquenta registrations onde metade deles eram acoplamentos disfarçados. O sistema parecia modulado, mas na prática uma mudança no banco quebrava a API inteira. Outro ponto importante é o uso de ViewModels. Não passe entidades do domínio direto para a view. Crie objetos específicos para cada tela. Isso parece burocracia, mas economiza tempo quando o requisito muda. Mudou um campo na tela? Altera o ViewModel, não a entidade. E se a entidade mudar de nome no banco? O ViewModel continua funcionando.

Erros comuns que todo mundo comete

O primeiro erro é achar que separação de responsabilidades é só sobre camadas. Ela vale também dentro da mesma camada. Um controller com duzentos métodos que faz tudo é tão problemático quanto um que conhece a view. Divida em múltiplos controllers ou use pattern de Action Filter para extrair lógica transversal. O segundo erro é confundir separação com complexidade desnecessária. Criar uma interface para cada método trivial não adiciona valor. Use o senso comum. Se algo é usado por um único componente, não precisa de abstração. A regra prática que eu sigo é: só abstraio quando tenho mais de um consumidor ou quando preciso substituir a implementação em teste. O terceiro erro, e o mais difícil de identificar, é o acoplamento conceitual. Duas partes do sistema podem não compartilhar código, mas compartilham pressupostos. Um exemplo clássico: a camada de domínio assume que todos os IDs são inteiros, e a API expõe IDs como string. Ninguém chama o outro diretamente, mas qualquer integração quebra porque as expectativas não combinam. Resolve isso definindo contratos explícitos e validando-os em cada fronteira entre camadas.

Quando o princípio não se aplica

Não adianta seguir a regra cegamente. Em scripts pequenos, utilitários internos ou proof of concept, separação rigorosa só atrapalha. Eu tenho um repositório com scripts de migração que são propositalmente monolíticos porque o propósito é executar uma vez e sumir. Colocar camada de abstração ali seria gasto desnecessário. Também existem situações onde comunicação direta entre camadas é aceitável. Se você tem um sistema legado que não pode ser refatorado no momento, criar adaptadores para tudo pode levar mais tempo do que o benefício que gera. Nesse caso, documente o acoplamento explicitamente e planeje uma migração gradual. Deixar o código acoplado sem registro é pedir para alguém no futuro gastar o triplo do tempo entendendo o que aconteceu.

Alternativas e ferramentas úteis

Se o conceito de separação de responsabilidades está difícil de manter em projetos grandes, considere usar um framework que force essa divisão. MediatR, por exemplo, impõe que handlers sejam isolados e que a comunicação entre eles passe por um mediador. Não resolve tudo, mas elimina uma categoria inteira de acoplamento direto. Para quem prefere não adicionar dependências, o padrão Repository já ajuda bastante. Ele isola a lógica de acesso a dados do resto do sistema. O downside é que implementações ingênuas de Repository podem virar um god object que faz tudo. A solução é manter cada repositório focado em uma única aggregate root. Outra alternativa é o CQRS, especialmente em sistemas com leituras muito diferentes das escritas. Separa completamente os modelos de leitura e escrita, o que elimina boa parte da tentação de misturar responsabilidades. O custo é maior complexidade inicial e mais código boilerplate. Só vale a pena quando o problema justifica.

O princípio de que cada parte do sistema deve desconhecer os detalhes internos das outras continua sendo um dos mais subestimados na prática. A maioria dos bugs de integração e das dificuldades de manutenção vem de violações silenciosas dessa regra, não de erros de lógica. Manter o código limpo nesse aspecto exige disciplina, mas o retorno em produtividade aparece depois de três ou quatro meses, não na primeira semana.