16. Camada anticorrupção e integração com legados

Este capítulo nasce das 30 questões publicadas sobre Camada anticorrupção e integração com legados. A leitura do acervo revelou 30 núcleos de conhecimento, aqui reorganizados como uma explicação progressiva: primeiro o vocabulário e o modelo mental, depois os mecanismos, as decisões de implementação, os limites e a forma de verificar o comportamento do sistema.

Depois de entender o fluxo de desenvolvimento, aprofundamos a modelagem do negócio. O DDD organiza conhecimento, linguagem, limites e regras para que o software represente o domínio com clareza. Este é o capítulo 16 de 20 da disciplina Domain-Driven Design (DDD). Ele retoma Context mapping e relações entre contextos e utiliza essa base para avançar. Na sequência, estudaremos Arquiteturas para DDD: camadas, hexagonal, onion e clean.

O fio condutor

O desenvolvimento de software começa com um problema e avança por decisões que precisam permanecer compreensíveis e verificáveis. Requisitos orientam modelos; modelos orientam código e arquitetura; testes verificam comportamento; e a operação devolve informações para o próximo ciclo. Uma falha importante no início tende a se espalhar pelas etapas seguintes.

Neste capítulo, use Camada anticorrupção e integração com legados para acompanhar quatro perguntas: qual problema precisa ser resolvido, como o mecanismo funciona, que consequências a escolha produz e como o resultado será verificado. Essa sequência transforma termos técnicos em decisões que podem ser explicadas e testadas.

Parte 1 — Fundamentos e vocabulário

Começamos por Parte 1 — Fundamentos e vocabulário, pois essa base organiza os conceitos e exemplos que aparecerão no restante do capítulo.

Item reproduz com fidelidade a definição de Evans: a anticorruption layer

O ponto de partida é estabelecer o significado do conceito e o problema que ele procura organizar. O item reproduz com fidelidade a definição de Evans: a anticorruption layer é uma camada de isolamento que oferece aos clientes funcionalidade do outro sistema expressa no modelo do próprio contexto consumidor, fazendo a tradução entre os dois modelos nas duas direções da comunicação. O nome engana: não se trata de barreira de segurança ou de controle de acesso, e sim de defesa SEMÂNTICA — o que se evita é a contaminação do modelo novo por conceitos alheios. Na prática, um contexto de Vendas que consulta clientes em um CRM legado recebe da camada objetos Cliente do seu próprio modelo, sem nunca manipular as estruturas do CRM. Sem essa mediação, cada integração direta importaria um pedaço do modelo antigo para dentro do novo. A regra ganha sentido quando suas consequências orientam a implementação.

Para aplicar Item reproduz com fidelidade a definição de Evans: a anticorruption layer, acompanhe a execução desde a entrada até a saída e anote pré-condições, mudança de estado, custo e falhas possíveis. Assim o conceito deixa de ser um rótulo e passa a orientar decisões.

Use como teste da compreensão: No Domain-Driven Design, a camada anticorrupção (anticorruption layer) é uma camada de isolamento que permite a um bounded context comunicar-se com um sistema legado nos termos do seu próprio modelo de domínio, realizando internamente a tradução necessária entre os dois modelos. Depois verifique a afirmação com execução controlada, teste automatizado, análise do contrato, medição ou documentação da versão correspondente. A evidência deve reproduzir a propriedade afirmada, inclusive nos casos de erro e de fronteira.

Anticorruption layer vive do lado DOWNSTREAM

A partir dessa distinção, o próximo elemento completa o fluxo. A anticorruption layer vive do lado DOWNSTREAM: é o contexto consumidor que a projeta, implementa e mantém, dentro da sua própria fronteira, como mecanismo de defesa do seu modelo. O upstream frequentemente nem sabe que a camada existe — ela consome as interfaces que o legado já oferece e faz a tradução na chegada. Isso decorre da própria motivação do padrão: quem tem um modelo a proteger é o consumidor; o legado não precisa de proteção contra quem apenas o lê. Quando é o provedor que publica um conjunto de serviços estáveis para facilitar o consumo, o que se tem é outro padrão de contexto (open host service), não uma ACL. Observe como definição, mecanismo e efeito permanecem ligados.