Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Implémentez une façade ou une couche d’adaptateur entre différents sous-systèmes qui ne partagent pas la même sémantique. Cette couche traduit les demandes qu’un sous-système effectue vers l’autre sous-système. Utilisez ce modèle pour vous assurer que les dépendances sur les sous-systèmes externes ne limitent pas la conception d’une application. Eric Evans a d’abord décrit ce modèle dans Domain-Driven Design : S’attaquer à la complexité au cœur du logiciel.
Contexte et problème
La plupart des applications s’appuient sur d’autres systèmes pour certaines données ou fonctionnalités. Par exemple, lorsque vous migrez une application héritée vers un système moderne, l’application peut continuer à utiliser des ressources héritées existantes. De nouvelles fonctionnalités doivent pouvoir appeler le système existant. Cette fonctionnalité est particulièrement importante pour les migrations progressives dans lesquelles vous déplacez différentes fonctionnalités d’une application plus grande vers un système moderne au fil du temps.
Ces systèmes hérités présentent souvent des problèmes de qualité tels que des schémas de données complexes ou des API obsolètes. Les fonctionnalités et technologies utilisées par les systèmes hérités peuvent varier largement des systèmes plus modernes. Pour interagir avec le système hérité, la nouvelle application peut avoir besoin de prendre en charge l’infrastructure, les protocoles, les modèles de données obsolètes, les API ou d’autres fonctionnalités que vous ne souhaitez pas mettre dans une application moderne.
Lorsque vous conservez l’accès entre les systèmes nouveaux et hérités, vous forcez le nouveau système à respecter au moins certaines API du système hérité ou d’autres sémantiques. Lorsque ces fonctionnalités héritées présentent des problèmes de qualité, cette prise en charge endommage ce qui pourrait autrement être une application moderne correctement conçue.
Des problèmes similaires peuvent survenir avec n’importe quel système externe que votre équipe de développement ne contrôle pas.
Solution
Isolez les différents sous-systèmes en plaçant une couche anti-corruption entre elles. Cette couche traduit la communication entre les deux systèmes. En utilisant cette approche, vous pouvez conserver un système inchangé sans compromettre la conception et l’approche technologique de l’autre.
Téléchargez un fichier Visio de cette architecture.
Le diagramme montre une application qui a deux sous-systèmes. Le sous-système A appelle le sous-système B par le biais d’une couche anti-corruption. La communication entre le sous-système A et la couche anti-corruption utilise toujours le modèle de données et l’architecture du sous-système A. Les appels de la couche anti-corruption au sous-système B sont conformes au modèle ou aux méthodes de données de ce sous-système. La couche anti-corruption contient toute la logique nécessaire pour traduire entre les deux systèmes. Vous pouvez implémenter la couche en tant que composant au sein de l’application ou en tant que service indépendant.
Problèmes et considérations
Tenez compte des points suivants lorsque vous décidez comment implémenter ce modèle :
La couche anti-corruption ajoute une latence aux appels entre les deux systèmes.
La couche anti-corruption ajoute un service supplémentaire que vous devez gérer et maintenir.
Réfléchissez à la façon dont vous envisagez de mettre à l’échelle la couche anti-corruption.
Déterminez si vous avez besoin de plusieurs couches anti-corruption. Par exemple, vous souhaiterez peut-être décomposer les fonctionnalités en plusieurs services qui utilisent différentes technologies ou langages.
Réfléchissez à la façon dont vous envisagez de gérer la couche anti-corruption par rapport à vos autres applications ou services, et comment l’intégrer dans vos processus de supervision, de mise en production et de configuration.
Assurez-vous de maintenir et de surveiller la cohérence des transactions et des données.
Déterminez si la couche anti-corruption doit gérer toutes les communications entre différents sous-systèmes ou simplement un sous-ensemble de fonctionnalités.
Si la couche anti-corruption fait partie d’une stratégie de migration d’application, déterminez s’il est permanent ou si vous envisagez de le mettre hors service après la migration de toutes les fonctionnalités héritées.
Le diagramme précédent utilise des sous-systèmes distincts pour illustrer ce modèle, mais vous pouvez également l’appliquer à d’autres architectures de service, telles que l’intégration de code héritée dans une architecture monolithique.
Étant donné que la couche anticorruption fait l’intermédiaire entre des systèmes susceptibles d’avoir des niveaux de confiance différents, envisagez d’appliquer la validation et l’assainissement des entrées à cette frontière.
Planifiez l’observabilité, y compris les ID de corrélation et la journalisation structurée, pour diagnostiquer les échecs de traduction.
Quand utiliser ce modèle
Utilisez ce modèle dans les situations suivantes :
Vous planifiez une migration sur plusieurs étapes, mais vous devez maintenir l’intégration entre les systèmes nouveaux et hérités.
Deux sous-systèmes ou plus ont une sémantique différente, mais ils doivent communiquer.
Ce modèle peut ne pas convenir lorsque :
- Les nouveaux systèmes hérités n’ont pas de différences sémantiques significatives. Dans ce scénario, il est important de concentrer la couche anti-corruption sur la logique de traduction. Évitez de placer des règles métier ou une orchestration dans la couche.
Conception de la charge de travail
Évaluez comment utiliser le modèle de couche anti-corruption dans la conception d'une charge de travail pour répondre aux objectifs et principes abordés dans les piliers Azure Well-Architected Framework. Le tableau suivant fournit des conseils sur la façon dont ce modèle prend en charge les objectifs de chaque pilier.
| Pilier | Comment ce modèle soutient les objectifs des piliers. |
|---|---|
| L’excellence opérationnelle permet de fournir une qualité de charge de travail grâce à des processus standardisés et à la cohésion de l’équipe. | Ce modèle permet de s’assurer que la conception de nouveaux composants reste non intégrée par les implémentations héritées qui peuvent avoir des modèles de données ou des règles métier différentes lorsque vous intégrez ces systèmes hérités. Il peut réduire la dette technique dans de nouveaux composants tout en prenant toujours en charge les composants existants. - OE :04 Outils et processus - OE :07 Système de supervision |
Si ce modèle introduit des compromis au sein d’un pilier, considérez-les contre les objectifs des autres piliers.
Example
Ce modèle est conceptuel et provient de l’approche de développement logiciel de conception pilotée par le domaine. Azure services tels que Gestion des API Azure ou Azure Functions peuvent aider à gérer et à traduire des protocoles, mais l’objectif principal d’une couche anti-corruption consiste à protéger le modèle de domaine, et non à prescrire un choix spécifique de produit.
Dans l’exemple suivant, Gestion des API gère les problèmes d’exposition et de protocole externes. Azure Functions implémente la couche anti-corruption via le mappage de domaine entre le nouveau système et le système hérité. Azure Monitor et Application Insights fournissent l’observabilité dont vous avez besoin pour suivre la réussite et la latence de la traduction entre les deux sous-systèmes.
Au-delà de ce modèle synchrone de demande-réponse, la couche anti-corruption peut également utiliser une approche asynchrone basée sur les événements. En utilisant Azure Service Bus, Azure Event Grid ou Azure Event Hubs, la couche dissocie le domaine moderne des contraintes de débit du système hérité afin d'autoriser la traduction basée sur les messages pour les charges de travail à débit élevé ou hautement découplées.
Étapes suivantes
Explorez les modèles de conception cloud qui aident à gérer les transactions distribuées et à maintenir la cohérence des données, tels que le modèle de transaction de compensation et le modèle de transactions distribuées Saga.
Étant donné que la couche anticorruption peut devenir un point unique de défaillance, prévoyez des mécanismes de résilience à l’aide du modèle Retry, du modèle Circuit Breaker, du modèle Bulkhead et du modèle Health Endpoint Monitoring.