本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 依交易分解
<a name="decompose-transactions"></a>

在分散式系統中，應用程式通常必須呼叫多個微服務才能完成一項商業交易。為了避免延遲問題或兩階段遞交問題，您可以根據交易將微服務分組。如果您認為回應時間很重要，且不同的模組在封裝之後不會建立整體，則此模式是適當的。下表說明使用此模式的優點和缺點。


****  

| 優點 | 缺點 | 
| --- | --- | 
|  [See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/modernization-decomposing-monoliths/decompose-transactions.html) |  [See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/modernization-decomposing-monoliths/decompose-transactions.html)  | 

在下圖中，根據交易，保險整體分為多個微服務。

![依交易分解整體](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/modernization-decomposing-monoliths/images/decompose-by-transaction.png)


在保險系統中，索賠請求通常會在提交後標記給客戶。這表示如果沒有*客戶*微服務，就無法存在宣告服務。*銷售*和*客戶*封裝在一個微服務套件中，而商業交易需要與兩者協調。