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 das aplicações dependem de outros sistemas para alguns dados ou funcionalidades. Por exemplo, quando uma aplicação legada é migrada para um sistema moderno, poderá continuar a precisar de recursos legados existentes. As novas funcionalidades devem ser capazes de chamar o sistema legado. Isto é particularmente verdadeiro para migrações graduais, em que diferentes funcionalidades de uma aplicação maior são movidas para um sistema moderno ao longo do tempo.
Muitas vezes, estes sistemas legados apresentam problemas de qualidade, como esquemas de dados complexos ou APIs obsoletas. As funcionalidades e tecnologias utilizadas em sistemas legados podem variar amplamente das que são utilizadas em sistemas mais modernos. Para interagir com o sistema legado, a nova aplicação poderá ter suportar uma infraestrutura, protocolos, modelos de dados, APIs desatualizadas ou outras funcionalidades que, caso contrário, não seriam inseridas numa aplicação moderna.
Manter o acesso entre sistemas legados e novos pode forçar o novo sistema a concordar com, pelo menos, algumas das APIs ou outra semântica do sistema legado. Quando estas funcionalidades legadas têm problemas de qualidade, suportá-las irá “corromper” o que poderá ser uma aplicação moderna corretamente concebida.
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 de danos anti-corrupção contém toda a lógica necessária para a conversão entre os dois sistemas. A camada pode ser implementada como um componente na aplicação ou como um serviço independente.
Problemas e considerações
- A camada anti-corrupção pode adicionar latência a chamadas efetuadas entre os dois sistemas.
- A camada anti-corrupção adiciona um serviço adicional que tem de ser gerido e mantido.
- Considere a forma como a camada anti-corrupção será dimensionada.
- Considere se precisa de mais do que uma camada anti-corrupção. Pode querer decompor funcionalidades em vários serviços com as diferentes tecnologias ou idiomas, ou poderão existir outras razões para criar partições da camada anti-corrupção.
- Considere a forma como a camada anti-corrupção será gerida em relação a outros serviços ou aplicações. Como será integrada nos processos de monitorização, lançamento e configuração?
- Certifique-se de que a transação e consistência dos dados são mantidos e podem ser monitorizadas.
- 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 utilizar este padrão
Utilize este padrão quando:
- Estiver planeada uma migração em várias fases, mas a integração entre o sistema novo e o legado tiver de ser mantida.
- Dois ou mais subsistemas têm semânticas diferentes, mas ainda precisam se comunicar.
Este padrão pode não ser adequado se não existirem diferenças semânticas significativas entre o sistema novo e o legado.
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:
| Pilar | Como esse padrão suporta os objetivos do pilar |
|---|---|
| A Excelência Operacional ajuda a fornecer qualidade de carga de trabalho por meio de processos padronizados e coesão da equipe. | Esse padrão ajuda a garantir que o novo design de componentes não seja influenciado por implementações herdadas que podem ter modelos de dados ou regras de negócios diferentes quando você se integra a esses sistemas legados e pode reduzir a dívida técnica em novos componentes e, ao mesmo tempo, oferecer suporte a componentes existentes. - OE:04 Ferramentas e processos |
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.