6.使用有界上下文维护模型完整性

复杂应用程序中往往有多个模型在发挥作用，每个模型表示问题域的不同部分。理想情况下每个子域有一个模型，但是现实并非总是如此有时一个子域可能包含多个模型，一个模型可能跨域多个子域。模型之间需要交互来满足系统行为，当模型未被清晰理解被应用到某个具体的上下文时，模型会变的模糊和缺乏明确性，概念和逻辑会混乱，使用有界上下文可以保证模型的一致性且富有意义，勤于使用有界上下文是DDD取得成功的必要条件。

1. 单个模型的局限性

DDD强调模型是不断演化的，要精确反映业务逻辑，在获得新的领域见解后可以纳入模型之中，如果使用单个模型应用整个系统，可能会发现两个不同区域有些相似概念会混淆，因此需要将大型复杂系统拆分成多个代码模型。

1. 模型复杂性增加

   业务用例增加模型复杂度也会增加，模型之间概念和依赖的数量也会增加，会渐渐变的复杂。

2. 多个团队处理一个模型

   沟通成本高，效率低。拆分成多个模型，每个团队维护自己的模型，可以独自迭代。

3. 模型语言中歧义 商品这个概念

   订单系统：就是一份创建订单时的快照数据。

   商品系统：代表了现实世界的商品或者服务，包含丰富的属性、生命周期、状态。

4. 使用小模型集成历史遗留或者第三方代码会方便。

5. 领域模型并非企业模型

   对于BI来说使用系统的单个模型是有用的，这里用的是企业单个模型，但是企业模型无法表达领域的概念，也不能替代需要持续演化的领域模型。下图是发布订阅，领域模型在发生数据变化时发布消息用来丰富企业模型的数据。

image-20220729005350794.png

2.使用有界上下文划分和破除大模型

2.1 有界上下文划分依据

模型要放在对应的上下文中，用有界上下文去限定每个模型的边界，有界上下文的需求在大型系统中是清晰的，但是识别有界上下文边界的过程却非常具有挑战性，一般可以参考下面规则定义。

1. 围绕语言定义边界
   不同的专业术语在不同上下文中有不同的含义，比如产品这个概念如果在相同的模型中有多个含义，模型至少要划分成两个上下文。

2. 与业务能力保持一致
   业务能力通常是语言边界的强力指标，比如销售部门和客服部门对于单据概念有完全不同理解，可以将业务能力看成潜在上下文。但要仔细一些，问题域和业务能力有时不完全一致。

3. 围绕团队创建上下文
   让一个团队服务一个微服务，避免出现多个团队负责一个。

2.2 子域和有界上下文的差异

子域可以跨多个模型、一个模型可能跨多个子域（理想情况下模型和子域一对一映射），有界上下文是应用程序强制分离模型的具体技术实现，模型不能有界跨上下文。

2.3 实现有界上下文

微服务代码设计问题，还是之前的四层结构，前面介绍实现领域模型的时候介绍了，后续在战术设计里面会详细介绍，这是战术设计，在后面会详细说明。