Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Branche par modèle d'abstraction
<a name="branch-by-abstraction"></a>

Le motif Strangler Fig fonctionne bien lorsque vous pouvez intercepter les appels au périmètre du monolithe. Toutefois, si vous souhaitez moderniser des composants qui existent plus profondément dans la pile d'applications existante et qui ont des dépendances en amont, nous vous recommandons d'utiliser le modèle de branche par abstraction. Ce modèle vous permet d'apporter des modifications à la base de code existante pour permettre à la version modernisée de coexister en toute sécurité avec l'ancienne version sans provoquer de perturbations.

Pour utiliser correctement le modèle de branche par abstraction, procédez comme suit :

1. Identifiez les composants monolithes qui ont des dépendances en amont. 

1. Créez une couche d'abstraction qui représente les interactions entre le code à moderniser et ses clients.

1. Lorsque l'abstraction est en place, modifiez les clients existants pour qu'ils utilisent la nouvelle abstraction. 

1. Créez une nouvelle implémentation de l'abstraction avec les fonctionnalités retravaillées en dehors du monolithe. 

1. Passez l'abstraction à la nouvelle implémentation lorsque vous êtes prêt. 

1. Lorsque la nouvelle implémentation fournit toutes les fonctionnalités nécessaires aux utilisateurs et que le monolithe n'est plus utilisé, nettoyez l'ancienne implémentation. 

Le modèle de branche par abstraction est souvent confondu avec [les bascules de fonctionnalités](http://martinfowler.com/bliki/FeatureToggle.html), qui vous permettent également d'apporter des modifications à votre système de manière incrémentielle. La différence est que les boutons de fonctionnalité sont destinés à permettre le développement de nouvelles fonctionnalités et à les rendre invisibles pour les utilisateurs lorsque le système est en cours d'exécution. Les boutons de fonctionnalité sont donc utilisés au moment du déploiement ou de l'exécution pour choisir si une fonctionnalité ou un ensemble de fonctionnalités en particulier est visible dans l'application. Le branchement par abstraction est une technique de développement qui peut être combinée à des bascules de fonctionnalités pour passer de l'ancienne à la nouvelle implémentation.

Le tableau suivant explique les avantages et les inconvénients de l'utilisation de la branche par modèle d'abstraction.


****  

| Avantages | Inconvénients | 
| --- | --- | 
|  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/modernization-decomposing-monoliths/branch-by-abstraction.html)  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/modernization-decomposing-monoliths/branch-by-abstraction.html)  | 

L'illustration suivante montre le modèle de branche par abstraction pour un composant de *notification* dans le monolithe d'assurance. Cela commence par créer un résumé ou une interface pour la fonctionnalité de notification. Par petits incréments, les clients existants sont modifiés pour utiliser la nouvelle abstraction. Cela peut nécessiter de rechercher dans la base de code les appels APIs liés au composant *Notification*. Vous créez la nouvelle implémentation de la fonctionnalité de notification sous forme de microservice en dehors de votre monolithe et vous l'hébergez dans l'architecture modernisée. À l'intérieur de votre monolithe, votre interface d'abstraction nouvellement créée agit comme un courtier et annonce la nouvelle implémentation. Par petites étapes, vous transférez la fonctionnalité de notification vers la nouvelle implémentation, qui reste inactive jusqu'à ce qu'elle soit complètement testée et prête. Lorsque la nouvelle implémentation est prête, vous changez d'abstraction pour l'utiliser. Vous devriez utiliser un mécanisme de commutation qui peut être facilement inversé (comme une bascule de fonctionnalité) afin de pouvoir revenir facilement à l'ancienne fonctionnalité en cas de problème. Lorsque la nouvelle implémentation commence à fournir toutes les fonctionnalités de notification à vos utilisateurs et que le monolithe n'est plus utilisé, vous pouvez nettoyer l'ancienne implémentation et supprimer tout indicateur de fonctionnalité de commutation que vous auriez pu implémenter

![\[Décomposer les monolithes en microservices en utilisant le modèle de branche par abstraction\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/modernization-decomposing-monoliths/images/branch-by-abstraction.png)