Padrão da Camada Anticorrupção
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 o design de um aplicativo não seja limitado por dependências em subsistemas externos. Esse 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 herdado. Isso ocorre especialmente em migrações graduais, em que diferentes recursos de um aplicativo maior são movidos para um sistema moderno ao longo do tempo.
Geralmente, esses sistemas herdados sofrem de problemas de qualidade, como esquemas de dados complicados ou APIs obsoletas. Os recursos e tecnologias usados em sistemas herdados podem variar muito de sistemas mais modernos. Para interoperar com o sistema herdado, o novo aplicativo pode precisar dar suporte a infraestrutura desatualizada, protocolos, modelos de dados, APIs ou outros recursos que você não colocaria em um aplicativo moderno.
Manter o acesso entre sistemas novos e herdados pode forçar o novo sistema a aderir a pelo menos algumas das APIs do sistema herdado ou outra semântica. Quando esses recursos herdados têm problemas de qualidade, dar suporte a eles "corrompe" o que poderia ser um aplicativo moderno de design limpo.
Problemas semelhantes podem surgir com qualquer sistema externo que sua equipe de desenvolvimento não controla, não apenas sistemas herdados.
Solução
Isole os diferentes subsistemas colocando uma camada anticorrupção entre eles. Essa camada converte as comunicações entre os dois sistemas, permitindo que um sistema permaneça inalterado, enquanto o outro pode evitar comprometer seu design e abordagem tecnológica.
O diagrama acima mostra um aplicativo com 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. A camada pode ser implementada como um componente dentro do aplicativo ou como um serviço independente.
Problemas 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 diferentes tecnologias ou idiomas, ou pode haver outros motivos para particionar a camada anticorrupção.
- Considere como a camada anticorrupção será gerenciada em relação a outros aplicativos ou serviços. Como ele será integrado aos processos de monitoramento, versão e configuração?
- Verifique se a transação e a consistência de dados são mantidas e podem ser monitoradas.
- 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 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 se aplicar a outras arquiteturas de serviço, como ao integrar código herdado em uma arquitetura monolítica.
Quando usar esse padrão
Use esse padrão quando:
- Uma migração está planejada para ocorrer em vários estágios, mas a integração entre sistemas novos e herdados precisa ser mantida.
- Dois ou mais subsistemas têm semântica diferente, mas ainda precisam se comunicar.
Esse padrão poderá não ser adequado se não houver diferenças semânticas significativas entre sistemas novos e herdados.
Design de carga de trabalho
Um arquiteto deve avaliar como o padrão camada anticorrupção pode ser usado no design de sua carga de trabalho para atender às metas e princípios abordados nos pilares do Azure Well-Architected Framework. Por exemplo:
| Pilar | Como esse padrão apoia os objetivos do pilar |
|---|---|
| de Excelência Operacional ajuda a fornecer de qualidade da carga de trabalho por meio processos padronizados e coesão de equipe. | Esse padrão ajuda a garantir que o novo design de componente permaneça influenciado por implementações herdadas que possam ter diferentes modelos de dados ou regras de negócios quando você se integrar a esses sistemas herdados e isso pode reduzir a dívida técnica em novos componentes enquanto ainda dá suporte a componentes existentes. - Ferramentas e processos do OE:04 |
Tal como acontece com qualquer decisão de design, considere quaisquer compensações em relação aos objetivos dos outros pilares que possam ser introduzidos com este padrão.