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.

# Décomposer par transactions
<a name="decompose-transactions"></a>

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.