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 la conception d’une application n’est pas limitée par des dépendances sur des sous-systèmes extérieurs. Ce modèle a d’abord été décrit par Eric Evans dans Domain-Driven Design.
Contexte et problème
La plupart des applications s’appuient sur d’autres systèmes pour certaines données ou fonctionnalités. Par exemple, lorsqu’une application héritée est migrée vers un système moderne, il peut toujours avoir besoin de ressources héritées existantes. De nouvelles fonctionnalités doivent être en mesure d’appeler le système hérité. Cela est particulièrement vrai pour les migrations progressives, où différentes fonctionnalités d’une application plus grande sont déplacées vers un système moderne au fil du temps.
Souvent, ces systèmes hérités souffrent de problèmes de qualité tels que des schémas de données convolués ou des API obsolètes. Les fonctionnalités et technologies utilisées dans 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.
Le maintien de l’accès entre les systèmes nouveaux et hérités peut forcer le nouveau système à adhérer à au moins une partie des 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é, la prise en charge des « corruptions » peut être une application moderne propre.
Des problèmes similaires peuvent survenir avec n’importe quel système externe que votre équipe de développement ne contrôle pas, pas seulement les systèmes hérités.
Solution
Isolez les différents sous-systèmes en plaçant une couche anti-corruption entre elles. Cette couche traduit les communications entre les deux systèmes, ce qui permet à un système de rester inchangé, tandis que l’autre peut éviter de compromettre sa conception et son approche technologique.
Le diagramme ci-dessus montre une application avec deux sous-systèmes. Sous-système A appelle le sous-système B via 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. La couche peut être implémentée en tant que composant au sein de l’application ou en tant que service indépendant.
Problèmes et considérations
- La couche anti-corruption peut ajouter une latence aux appels effectués entre les deux systèmes.
- La couche anti-corruption ajoute un service supplémentaire qui doit être géré et géré.
- Réfléchissez à la façon dont votre couche anti-corruption sera mise à l’échelle.
- Déterminez si vous avez besoin de plusieurs couches anti-corruption. Vous souhaiterez peut-être décomposer les fonctionnalités en plusieurs services à l’aide de différentes technologies ou langages, ou il peut y avoir d’autres raisons de partitionner la couche anti-corruption.
- Réfléchissez à la façon dont la couche anti-corruption sera gérée par rapport à vos autres applications ou services. Comment sera-t-il intégré à vos processus de supervision, de mise en production et de configuration ?
- Assurez-vous que la cohérence des transactions et des données est maintenue et peut être surveillée.
- 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 sera permanent ou sera mis hors service une fois que toutes les fonctionnalités héritées ont été migrées.
- Ce modèle est illustré avec des sous-systèmes distincts ci-dessus, mais peut également s’appliquer à d’autres architectures de service, comme lors de l’intégration de code hérité ensemble dans une architecture monolithique.
Quand utiliser ce modèle
Utilisez ce modèle quand :
- Une migration est planifiée sur plusieurs étapes, mais l’intégration entre les systèmes nouveaux et hérités doit être maintenue.
- Deux sous-systèmes ou plus ont une sémantique différente, mais doivent toujours communiquer.
Ce modèle peut ne pas convenir s’il n’existe pas de différences sémantiques significatives entre les systèmes nouveaux et hérités.
Conception de la charge de travail
Un architecte doit évaluer la façon dont le modèle de couche anti-corruption peut être utilisé dans la conception de leur charge de travail pour répondre aux objectifs et principes couverts dans les piliers Azure Well-Architected Framework. Par exemple:
| Pilier | Comment ce modèle soutient les objectifs des piliers. |
|---|---|
| l’excellence opérationnelle permet de fournir qualité de la charge de travail grâce à processus standardisés et à la cohésion de l’équipe. | Ce modèle permet de s’assurer que la conception de nouveaux composants reste ininfluée par les implémentations héritées qui peuvent avoir différents modèles de données ou règles métier lorsque vous intégrez ces systèmes hérités et qu’elle peut réduire la dette technique dans les nouveaux composants tout en prenant en charge les composants existants. - OE :04 Outils et processus |
Comme pour toute autre décision de conception, il convient de prendre en compte les compromis par rapport aux objectifs des autres piliers qui pourraient être introduits avec ce modèle.