本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 按子域分解
<a name="decompose-subdomain"></a>

这种模式使用[域驱动设计 (DDD)](https://en.wikipedia.org/wiki/Domain-driven_design)子域来分解单体。这种方法将组织的域模型分解为单独的子域，这些子域被标记为*核心*（业务的关键差异化因素）、*支持*（可能与业务相关但与差异化因素无关）或*通用*（不是特定于业务）。这种模式适用于现有的单体系统，这些系统在子域相关模块之间具有明确定义的边界。这意味着您可以通过将现有模块重新打包为微服务来分解整体结构，而无需大量重写现有代码。每个子域都有一个模型，该模型的范围称为有*界限上下文*。微服务是围绕这种界限上下文开发的。下表说明了使用此模式的优势和劣势。


****  

| 优点 | 缺点 | 
| --- | --- | 
|  [See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/modernization-decomposing-monoliths/decompose-subdomain.html) | [See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/modernization-decomposing-monoliths/decompose-subdomain.html) | 

下图显示了保险单体在按业务能力分解后如何将其分解为子域。

![按子域分解单体](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/modernization-decomposing-monoliths/images/decompose-by-subdomain.png)


该插图显示，*销售*和*营销*服务被分解为较小的微服务。*采购*和*索赔*模型是*销售*的重要业务差异化因素，它们分为两个独立的微服务。通过使用*活动*、*分析*和*报告*等辅助业务功能来分解*营销*。