Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Implemente uma camada de fachada ou adaptador entre diferentes subsistemas que não compartilham a mesma semântica. Essa camada converte solicitações que um subsistema faz para o outro subsistema. Use esse padrão para garantir que as dependências em subsistemas externos não limitem o design de um aplicativo. Eric Evans descreveu pela primeira vez esse padrão em Domain-Driven Design: Abordando a complexidade no coração do software.
Contexto e problema
A maioria dos aplicativos depende de outros sistemas para alguns dados ou funcionalidades. Por exemplo, quando você migra um aplicativo herdado para um sistema moderno, o aplicativo pode continuar a usar recursos herdados existentes. Os novos recursos devem ser capazes de chamar o sistema legado. Essa funcionalidade é especialmente importante para migrações graduais nas quais você move diferentes recursos de um aplicativo maior para um sistema moderno ao longo do tempo.
Esses sistemas herdados geralmente têm problemas de qualidade, como esquemas de dados complicados ou APIs obsoletas. Os recursos e tecnologias que os sistemas herdados usam podem variar muito de sistemas mais modernos. Para interoperar com o sistema herdado, talvez o novo aplicativo precise dar suporte a infraestruturas desatualizadas, protocolos, modelos de dados, APIs ou outros recursos que você não colocaria em um aplicativo moderno.
Quando você mantém o acesso entre sistemas novos e herdados, força o novo sistema a aderir a pelo menos algumas das APIs do sistema herdado ou outra semântica. Quando essas funcionalidades legadas apresentam problemas de qualidade, esse suporte corrompe o que, de outra forma, poderia ser um aplicativo moderno com design limpo.
Problemas semelhantes podem surgir com qualquer sistema externo que sua equipe de desenvolvimento não controla.
Solução
Isole os diferentes subsistemas colocando uma camada anticorrupção entre eles. Essa camada converte a comunicação entre os dois sistemas. Usando essa abordagem, você pode manter um sistema inalterado sem comprometer o design e a abordagem tecnológica do outro.
Carrege um arquivo Visio desta arquitetura.
O diagrama mostra um aplicativo que tem dois subsistemas. O subsistema A chama o subsistema B por meio 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. Chamadas da camada anticorrupção para o subsistema B estão em conformidade com o modelo de dados ou métodos desse subsistema. A camada anticorrupção contém toda a lógica necessária para traduzir entre os dois sistemas. Você pode implementar a camada como um componente dentro do aplicativo ou como um serviço independente.
Problemas e considerações
Considere os seguintes pontos ao decidir como implementar esse padrão:
A camada anticorrupção adiciona latência a chamadas entre os dois sistemas.
A camada anticorrupção adiciona um serviço extra que você deve gerenciar e manter.
Considere como você planeja dimensionar a camada anticorrupção.
Considere se você precisa de mais de uma camada anticorrupção. Por exemplo, talvez você queira decompor a funcionalidade em vários serviços que usam diferentes tecnologias ou idiomas.
Considere como você planeja gerenciar a camada anticorrupção em relação a outros aplicativos ou serviços e como integrá-la aos processos de monitoramento, versão e configuração.
Certifique-se de manter e monitorar a consistência de transações e dados.
Considere se a camada anticorrupção precisa lidar com toda a comunicação entre subsistemas diferentes ou apenas um subconjunto de recursos.
Se a camada anticorrupção fizer parte de uma estratégia de migração de aplicativo, considere se ela é permanente ou se você planeja desapossá-la depois de migrar todas as funcionalidades herdadas.
O diagrama anterior usa subsistemas distintos para ilustrar esse padrão, mas você também pode aplicá-lo a outras arquiteturas de serviço, como integração de código herdado em uma arquitetura monolítica.
Como a camada anticorrupção media sistemas que podem ter níveis de confiança diferentes, considere impor a validação e a sanitização de entrada nesse limite.
Planeje a observabilidade, incluindo IDs de correlação e log estruturado, para diagnosticar falhas de tradução.
Quando usar esse padrão
Use esse padrão quando:
Você planeja que uma migração ocorra em vários estágios, mas precisa manter a integração entre sistemas novos e herdados.
Dois ou mais subsistemas têm semântica diferente, mas precisam se comunicar.
O padrão pode não ser adequado nestes casos:
- Os sistemas novos e herdados não têm diferenças semânticas significativas. Nesse cenário, é importante concentrar a camada anticorrupção na lógica de tradução. Evite colocar regras de negócios ou orquestração na camada.
Design de carga de trabalho
Avalie como usar o padrão de camada anticorrupção no projeto de uma carga de trabalho para atender às metas e aos princípios abordados nos pilares do Azure Well-Architected Framework. A tabela a seguir fornece diretrizes sobre como esse padrão dá suporte às metas de cada pilar.
| Pilar | Como esse padrão apoia os objetivos do pilar |
|---|---|
| A Excelência Operacional ajuda a fornecer qualidade da carga de trabalho por meio de processos padronizados e coesão de equipe. | Esse padrão ajuda a garantir que o novo design de componentes permaneça não influenciado por implementações legadas que possam ter diferentes modelos de dados ou regras de negócios quando integrados a esses sistemas legados. Ele pode reduzir a dívida técnica em novos componentes enquanto ainda dá suporte a componentes existentes. - OE:04 Ferramentas e processos - OE:07 Sistema de monitoramento |
Se esse padrão introduzir compensações dentro de um pilar, considere-as em relação aos objetivos dos outros pilares.
Example
Esse padrão é conceitual e se origina da abordagem de desenvolvimento de software de design orientada pelo domínio. Azure serviços como Gerenciamento de API do Azure ou Azure Functions podem ajudar no tratamento e tradução de protocolos, mas a finalidade principal de uma camada anticorrupção é proteger o modelo de domínio, não prescrever nenhuma escolha específica do produto.
No exemplo a seguir, o Gerenciamento de API lida com a exposição externa e as preocupações de protocolo. Azure Functions implementa a camada anticorrupção por meio do mapeamento de domínio entre o novo sistema e o sistema herdado. 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.
Além desse modelo síncrono de solicitação-resposta, a camada anticorrupção também pode usar uma abordagem assíncrona orientada a eventos. Usando Barramento de Serviço do Azure, Grade de Eventos do Azure ou Hubs de Eventos do Azure, a camada separa o domínio moderno das restrições de taxa de transferência do sistema herdado para permitir a tradução baseada em mensagem para cargas de trabalho de alta taxa de transferência ou altamente desacopladas.
Próximas Etapas
Explore os padrões de design de nuvem que ajudam a gerenciar transações distribuídas e manter a consistência de dados, como o padrão de transação de compensação e o padrão de transações distribuídas saga.
Como a camada anticorrupção pode se tornar um ponto único de falha, planeje a resiliência usando o padrão Retry, o padrão Circuit Breaker, o padrão Bulkhead e o padrão Health Endpoint Monitoring.