Padrão de camada anticorrupção

Implemente uma fachada ou camada de adaptador entre diferentes subsistemas que não compartilham a mesma semântica. Esta camada traduz as solicitações que um subsistema faz para o outro subsistema. Use esse padrão para garantir que o design de um aplicativo não seja limitado por dependências em subsistemas externos. Este padrão foi descrito pela primeira vez por Eric Evans em Domain-Driven Design.

Contexto e problema

A maioria dos aplicativos depende de outros sistemas para alguns dados ou funcionalidades. Por exemplo, quando um aplicativo herdado é migrado para um sistema moderno, ele ainda pode precisar de recursos herdados existentes. Novos recursos devem ser capazes de chamar o sistema legado. Isso é especialmente verdadeiro para migrações graduais, onde diferentes recursos de um aplicativo maior são movidos para um sistema moderno ao longo do tempo.

Muitas vezes, esses sistemas legados sofrem de problemas de qualidade, como esquemas de dados complicados ou APIs obsoletas. As características e tecnologias utilizadas em sistemas legados podem variar muito de 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.

Manter o acesso entre sistemas novos e legados pode forçar o novo sistema a aderir a pelo menos algumas das APIs ou outras semânticas do sistema legado. Quando esses recursos herdados têm problemas de qualidade, o suporte a eles "corrompe" o que poderia ser um aplicativo moderno projetado de forma limpa.

Problemas semelhantes podem surgir com qualquer sistema externo que sua equipe de desenvolvimento não controla, não apenas sistemas legados.

Solução

Isole os diferentes subsistemas colocando uma camada anticorrupção entre eles. Esta camada traduz as comunicações entre os dois sistemas, permitindo que um sistema permaneça inalterado enquanto o outro pode evitar comprometer o seu design e abordagem tecnológica.

O diagrama acima mostra uma aplicação com 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. A camada pode ser implementada como um componente dentro do aplicativo ou como um serviço independente.

Questões e considerações

• A camada anticorrupção pode adicionar latência às chamadas feitas entre os dois sistemas.
• A camada anticorrupção adiciona um serviço adicional que deve ser gerenciado e mantido.
• Considere como sua camada anticorrupção será dimensionada.
• Considere se você precisa de mais de uma camada anticorrupção. Talvez você queira decompor a funcionalidade em vários serviços usando tecnologias ou linguagens diferentes, ou pode haver outros motivos para particionar a camada anticorrupção.
• Considere como a camada anticorrupção será gerenciada em relação aos seus outros aplicativos ou serviços. Como ele será integrado aos seus processos de monitoramento, liberação e configuração?
• Certifique-se de que a consistência da transação e dos dados seja mantida e possa ser monitorada.
• 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 fizer parte de uma estratégia de migração de aplicativos, considere se ela será permanente ou será desativada depois que todas as funcionalidades herdadas forem migradas.
• Esse padrão é ilustrado com subsistemas distintos acima, mas também pode ser aplicado a outras arquiteturas de serviço, como ao integrar código herdado em uma arquitetura monolítica.

Quando usar este padrão

Utilize este padrão quando:

• Uma migração está planejada para acontecer em vários estágios, mas a integração entre sistemas novos e legados precisa ser mantida.
• Dois ou mais subsistemas têm semânticas diferentes, mas ainda precisam se comunicar.

Esse padrão pode não ser adequado se não houver diferenças semânticas significativas entre sistemas novos e legados.

Design da carga de trabalho

Um arquiteto deve avaliar como o padrão de Camada Anticorrupção pode ser usado no design de sua carga de trabalho para abordar as metas e os princípios abordados nos pilares do Azure Well-Architected Framework. Por exemplo:

Como em qualquer decisão de design, considere quaisquer compensações em relação aos objetivos dos outros pilares que possam ser introduzidos com esse padrão.

Recursos relacionados

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