Branche par modèle d'abstraction

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

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

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

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

3. Lorsque l'abstraction est en place, modifiez les clients existants pour utiliser la nouvelle abstraction.

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

5. Basculez l'abstraction vers la nouvelle implémentation lorsque vous êtes prête.

6. 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 options de fonctionnalité, qui vous permettent également d'apporter des modifications incrémentielles à votre système. La différence réside dans le fait que les bascules de fonctionnalités sont destinées à permettre le développement de nouvelles fonctionnalités et à les rendre invisibles aux utilisateurs lorsque le système est en cours d'exécution. Les options de fonctionnalité sont donc utilisées au moment du déploiement ou de l'exécution pour choisir si une fonctionnalité ou un ensemble de fonctionnalités particulier est visible dans l'application. Le branchement par abstraction est une technique de développement qui peut être combinée à des fonctionnalités permettant de basculer entre l'ancienne et 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

Permet des modifications incrémentielles qui sont réversibles en cas de problème (rétrocompatible). Vous permet d'extraire les fonctionnalités qui se trouvent au plus profond du monolithe lorsque vous ne pouvez pas intercepter les appels qui lui sont adressés en périphérie du monolithe. Permet à plusieurs implémentations de coexister dans le système logiciel. Fournit un moyen simple de mettre en œuvre un mécanisme de secours en utilisant une étape de vérification intermédiaire pour appeler à la fois les nouvelles et les anciennes fonctionnalités. Prend en charge la livraison continue, car votre code fonctionne à tout moment tout au long de la phase de restructuration.

Ne convient pas si la cohérence des données est en jeu. Nécessite des modifications du système existant. Cela peut alourdir le processus de développement, en particulier si la base de code est mal structurée. (Dans de nombreux cas, l'avantage vaut l'effort supplémentaire, et plus la restructuration est importante, plus il est important d'envisager d'utiliser la branche par modèle d'abstraction.)

L'illustration suivante montre le modèle de branche par abstraction pour un composant de notification dans le monolithe d'assurance. Cela commence par la création d'un résumé ou d'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 aux API 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 en tant que courtier et appelle la nouvelle implémentation. Par petits incréments, vous transférez la fonctionnalité de notification vers la nouvelle implémentation, qui reste inactive jusqu'à ce qu'elle soit entièrement testée et prête. Lorsque la nouvelle implémentation est prête, vous basculez votre abstraction pour l'utiliser. Vous souhaiterez utiliser un mécanisme de commutation qui peut être facilement inversé (tel qu'un basculement 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