Padrão da Camada Anti-Corrupção

Implemente uma camada de fachada ou adaptador entre diferentes subsistemas que não partilhem a mesma semântica. Esta camada traduz as solicitações que um subsistema faz para o outro subsistema. Use este padrão para garantir que as dependências de subsistemas externos não limitam o design de uma aplicação. Eric Evans descreveu este padrão pela primeira vez em Domain-Driven Design: Tackling Complexity in the Heart of Software.

Contexto e problema

A maioria dos aplicativos depende de outros sistemas para alguns dados ou funcionalidades. Por exemplo, quando migra uma aplicação legada para um sistema moderno, a aplicação pode continuar a usar recursos legados existentes. Novos recursos devem ser capazes de acessar o sistema legado. Esta capacidade é especialmente importante para migrações graduais, nas quais se transferem diferentes funcionalidades de uma aplicação maior para um sistema moderno ao longo do tempo.

Estes sistemas legados frequentemente apresentam problemas de qualidade, como esquemas de dados complexos ou APIs obsoletas. As funcionalidades e tecnologias que os sistemas legados utilizam podem variar bastante dos sistemas mais modernos. Para interoperar com o sistema herdado, o novo aplicativo pode precisar oferecer suporte a infraestrutura, protocolos, modelos de dados, APIs ou outros recursos desatualizados que, de outra forma, você não colocaria em um aplicativo moderno.

Quando mantém o acesso entre sistemas novos e legados, obriga o novo sistema a cumprir pelo menos algumas das APIs ou outras semânticas do sistema legado. Quando estas funcionalidades legadas apresentam problemas de qualidade, este suporte corrompe o que poderia ser uma aplicação moderna e bem desenhada.

Problemas semelhantes podem surgir em qualquer sistema externo que a sua equipa de desenvolvimento não controle.

Solução

Isole os diferentes subsistemas colocando uma camada anticorrupção entre eles. Esta camada traduz a comunicação entre os dois sistemas. Ao usar esta abordagem, pode manter um sistema inalterado sem comprometer o design e a abordagem tecnológica do outro.

Descarregue um ficheiro Visio desta arquitetura.

O diagrama mostra uma aplicação que tem dois subsistemas. O subsistema A chama o subsistema B através de uma camada anticorrupção. A comunicação entre o subsistema A e a camada anticorrupção sempre usa o modelo de dados e a arquitetura do subsistema A. As chamadas da camada anticorrupção para o subsistema B estão em conformidade com o modelo ou métodos de dados desse subsistema. A camada anticorrupção contém toda a lógica necessária para traduzir entre os dois sistemas. Pode implementar a camada como um componente dentro da aplicação ou como um serviço independente.

Problemas e considerações

Considere os seguintes pontos ao decidir como implementar este padrão:

• A camada anticorrupção adiciona latência às chamadas entre os dois sistemas.

• A camada anticorrupção adiciona um serviço extra que deve gerir e manter.

• Considere como planeia escalar a camada anticorrupção.

• Considere se você precisa de mais de uma camada anticorrupção. Por exemplo, pode querer decompor funcionalidades em múltiplos serviços que utilizam tecnologias ou linguagens diferentes.

• Considere como planeia gerir a camada anticorrupção em relação às suas outras aplicações ou serviços, e como a integrar nos seus processos de monitorização, lançamento e configuração.

• Certifique-se de manter e monitorizar a consistência das transações e dos dados.

• Considere se a camada anticorrupção precisa lidar com toda a comunicação entre diferentes subsistemas ou apenas um subconjunto de recursos.

• Se a camada anticorrupção faz parte de uma estratégia de migração de aplicações, considere se é permanente ou se planeia aposentá-la depois de migrar toda a funcionalidade legada.

• O diagrama anterior utiliza subsistemas distintos para ilustrar este padrão, mas também pode aplicá-lo a outras arquiteturas de serviços, como a integração de código legado numa arquitetura monolítica.

• Como a camada anticorrupção media sistemas que podem ter diferentes níveis de confiança, considere impor validação e sanitização de entrada neste limite.

• Planeie a observabilidade, incluindo IDs de correlação e registos estruturados, para diagnosticar falhas de tradução.

Quando utilizar este padrão

Utilize este padrão quando:

• Planeias que a migração ocorra em várias fases, mas precisas de manter a integração entre sistemas novos e antigos.

• Dois ou mais subsistemas têm semântica diferente, mas precisam de comunicar.

Este padrão pode não ser adequado quando:

• Os sistemas novos e legados não apresentam diferenças semânticas significativas. Neste cenário, é importante focar a camada anticorrupção na lógica de tradução. Evite colocar regras de negócio ou orquestração na camada.

Design da carga de trabalho

Avalie como utilizar o padrão Anti-Corruption Layer na conceção de uma carga de trabalho para cumprir os objetivos e princípios definidos nos pilares do Azure Well-Architected Framework. A tabela a seguir fornece orientação sobre como esse padrão suporta as metas de cada pilar.

Se este padrão introduzir compensações dentro de um pilar, considere-as em relação aos objetivos dos outros pilares.

Example

Este padrão é conceptual e tem origem na abordagem de desenvolvimento de software orientada por domínio. Serviços do Azure como API Management do Azure ou Funções do Azure podem ajudar no tratamento e tradução de protocolos, mas o objetivo principal de uma camada anticorrupção é proteger o modelo de domínio, não prescrever uma escolha específica de produto.

No exemplo seguinte, a Gestão de APIs trata da exposição externa e das preocupações relacionadas com o protocolo. O Funções do Azure implementa a camada anticorrupção através do mapeamento de domínio entre o novo sistema e o sistema legado. Azure Monitor e Application Insights fornecem a observabilidade necessária para acompanhar o sucesso e a latência da tradução entre os dois subsistemas.

Para além deste modelo síncrono de pedido-resposta, a camada anticorrupção pode também usar uma abordagem assíncrona orientada por eventos. Ao utilizar Azure Service Bus, Azure Event Grid ou Hubs de Eventos do Azure, a camada desacopla o domínio moderno das restrições de throughput do sistema legado para permitir a tradução baseada em mensagens para cargas de trabalho de alto débito ou altamente desacopladas.

Passos seguintes

• Explore padrões de design de cloud que ajudam a gerir transações distribuídas e a manter a consistência dos dados, como o padrão Compensating Transaction e o padrão de transações distribuídas Saga.

• Como a camada anti-corrupção pode tornar-se um ponto único de falha, planeie a resiliência utilizando o padrão Retry, padrão Circuit Breaker, padrão Bulkhead e padrão Health Endpoint Monitoring.

Recursos relacionados

• Padrão de figo Strangler
• Padrão de ponte de mensagens