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.

# Modèles pour la décomposition des monolithes


Après avoir décidé de décomposer un monolithe dans votre portefeuille d'applications, vous devez choisir les modèles de décomposition appropriés et les introduire dans votre organisation. 

**Note**  
Vous pouvez utiliser plusieurs modèles pour décomposer un monolithe. Par exemple, vous pouvez décomposer un monolithe par [capacité commerciale](decompose-business-capability.md), puis utiliser le [modèle de sous-domaine](decompose-subdomain.md) pour le décomposer davantage.

**Topics**
+ [

# Décomposer selon les capacités de l'entreprise
](decompose-business-capability.md)
+ [

# Décomposer par sous-domaine
](decompose-subdomain.md)
+ [

# Décomposer par transactions
](decompose-transactions.md)
+ [

# Modèle de service par équipe
](service-per-team.md)
+ [

# Motif Strangler Fig
](strangler-fig.md)
+ [

# Branche par modèle d'abstraction
](branch-by-abstraction.md)

# Décomposer selon les capacités de l'entreprise


Vous pouvez utiliser les processus métier ou les capacités de votre organisation pour décomposer un monolithe. Une *capacité commerciale* est ce qu'une entreprise fait pour générer de la valeur (par exemple, les ventes, le service client ou le marketing). En règle générale, une organisation possède de multiples capacités commerciales, qui varient selon le secteur ou le secteur d'activité. Utilisez ce modèle si votre équipe possède une connaissance suffisante des unités commerciales de votre organisation et si vous disposez d'experts en la matière (SMEs) pour chaque unité commerciale. Le tableau suivant explique les avantages et les inconvénients de l'utilisation de ce modèle.


****  

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

Dans le schéma suivant, un monolithe d'assurance est décomposé en quatre microservices basés sur les capacités de l'entreprise. 

![\[Décomposer les monolithes en fonction des capacités de l'entreprise\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/modernization-decomposing-monoliths/images/decompose-by-business-capability.png)


# Décomposer par sous-domaine


Ce modèle utilise un [sous-domaine de conception pilotée par domaine (DDD)](https://en.wikipedia.org/wiki/Domain-driven_design) pour décomposer les monolithes. Cette approche décompose le modèle de domaine de l'organisation en sous-domaines distincts qui sont étiquetés comme *principaux* (un facteur de différenciation clé pour l'entreprise), *support* (peut-être lié à l'activité mais pas un facteur de différenciation) ou *génériques* (non spécifiques à l'entreprise). Ce modèle convient aux systèmes monolithiques existants qui ont des limites bien définies entre les modules liés aux sous-domaines. Cela signifie que vous pouvez décomposer le monolithe en reconditionnant les modules existants sous forme de microservices, mais sans réécrire de manière significative le code existant. Chaque sous-domaine possède un modèle, et la portée de ce modèle est appelée contexte *limité*. Les microservices sont développés dans ce contexte limité. Le tableau suivant explique les avantages et les inconvénients de l'utilisation de ce modèle.


****  

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

L'illustration suivante montre comment un monolithe d'assurance peut être décomposé en sous-domaines après avoir été décomposé par les capacités de l'entreprise.

![\[Décomposer les monolithes par sous-domaines\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/modernization-decomposing-monoliths/images/decompose-by-subdomain.png)


L'illustration montre que les services *de vente* et de *marketing* sont divisés en microservices plus petits. Les modèles *d'achat* et de *réclamation* sont des facteurs de différenciation commerciaux importants pour les *ventes* et sont divisés en deux microservices distincts. Le *marketing* est décomposé en utilisant des fonctionnalités commerciales complémentaires telles que les *campagnes*, les *analyses* et les *rapports*.

# Décomposer par transactions


Dans un système distribué, une application doit généralement appeler plusieurs microservices pour effectuer une transaction commerciale. Pour éviter les problèmes de latence ou les problèmes de validation en deux phases, vous pouvez regrouper vos microservices en fonction des transactions. Ce modèle est approprié si vous considérez que les temps de réponse sont importants et que vos différents modules ne créent pas de monolithe une fois que vous les avez empaquetés. Le tableau suivant explique les avantages et les inconvénients de l'utilisation de ce modèle.


****  

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

Dans l'illustration suivante, le monolithe d'assurance est décomposé en plusieurs microservices basés sur les transactions. 

![\[Décomposer les monolithes par transactions\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/modernization-decomposing-monoliths/images/decompose-by-transaction.png)


Dans un système d'assurance, une demande de réclamation est généralement adressée à un client une fois qu'elle a été soumise. Cela signifie qu'un service de réclamation ne peut exister sans un microservice *destiné aux clients*. Les *ventes* et les *clients* sont regroupés dans un seul ensemble de microservices, et une transaction commerciale nécessite une coordination avec les deux. 

# Modèle de service par équipe


Au lieu de décomposer les monolithes en fonction des capacités ou des services de l'entreprise, le modèle de service par équipe les décompose en microservices gérés par des équipes individuelles. Chaque équipe est responsable d'une fonctionnalité commerciale et possède la base de code de cette fonctionnalité. L'équipe développe, teste, déploie ou fait évoluer ses services de manière indépendante, et interagit principalement avec d'autres équipes pour négocier. APIs Nous vous recommandons d'attribuer chaque microservice à une seule équipe. Toutefois, si l'équipe est suffisamment importante, plusieurs sous-équipes peuvent posséder des microservices distincts au sein de la même structure d'équipe. Le tableau suivant explique les avantages et les inconvénients de l'utilisation de ce modèle.


****  

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

L'illustration suivante montre comment un monolithe peut être divisé en microservices gérés, maintenus et fournis par des équipes individuelles.

![\[Décomposer les monolithes en microservices par les équipes\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/modernization-decomposing-monoliths/images/service-per-team.png)


# Motif Strangler Fig


Les modèles de conception décrits jusqu'à présent dans ce guide s'appliquent aux applications de décomposition pour des projets entièrement nouveaux. Qu'en est-il des projets de friches industrielles impliquant de grandes applications monolithiques ? Il sera difficile de leur appliquer les modèles de conception précédents, car les diviser en petits morceaux lorsqu'ils sont utilisés activement est une tâche ardue.

Le motif [Strangler Fig est un motif](https://martinfowler.com/bliki/StranglerFigApplication.html) populaire qui a été introduit par Martin Fowler, qui s'est inspiré d'un certain type de figue qui se répand dans les branches supérieures des arbres. L'arbre existant devient initialement une structure de support pour le nouveau figuier. La figue envoie ensuite ses racines au sol, enveloppant progressivement l'arbre d'origine et ne laissant à sa place que le nouveau figuier autoportant. 

Ce modèle est couramment utilisé pour transformer progressivement une application monolithique en microservices en remplaçant une fonctionnalité particulière par un nouveau service. L'objectif est de faire coexister l'ancienne version avec les nouvelles versions modernisées. Le nouveau système est initialement soutenu par le système existant et le complète. Cette prise en charge donne au nouveau système le temps de se développer et éventuellement de remplacer entièrement l'ancien système.

Le processus de transition d'une application monolithique à des microservices en implémentant le modèle Strangler Fig comprend trois étapes : transformer, coexister et éliminer : 
+ *Transformation* : identifiez et créez des composants modernisés en les portant ou en les réécrivant en parallèle avec l'ancienne application. 
+ *Coexister* — Conservez l'application monolithe pour la restauration. Interceptez les appels système extérieurs en incorporant un proxy HTTP (par exemple, [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html)) au périmètre de votre monolithe et redirigez le trafic vers la version modernisée. Cela vous permet de mettre en œuvre les fonctionnalités de manière incrémentielle. 
+ *Élimination* : retirez l'ancienne fonctionnalité du monolithe à mesure que le trafic est redirigé du monolithe existant vers le service modernisé. 

Le tableau suivant explique les avantages et les inconvénients de l'utilisation du motif Strangler Fig.


****  

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

L'illustration suivante montre comment un monolithe peut être divisé en microservices en appliquant le modèle Strangler Fig à une architecture d'application. Les deux systèmes fonctionnent en parallèle, mais vous allez commencer à déplacer les fonctionnalités en dehors de la base de code monolithe et à les améliorer grâce à de nouvelles fonctionnalités. Ces nouvelles fonctionnalités vous permettent de concevoir des microservices de la manière la mieux adaptée à vos besoins. Vous allez continuer à supprimer les fonctionnalités du monolithe jusqu'à ce qu'il soit entièrement remplacé par des microservices. À ce stade, vous pouvez éliminer l'application monolithe. Le point essentiel à noter ici est que le monolithe et les microservices vont cohabiter pendant un certain temps.

![\[Décomposer les monolithes en microservices en utilisant le modèle Strangler Fig\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/modernization-decomposing-monoliths/images/strangler-fig.png)


# Branche par modèle d'abstraction


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)