DDD领域驱动实战(二)-限界上下文(bounded context)

1 前言

"First, a Bounded Contextis a semantic contextual boundary. Thismeans that within the boundary each component of the softwaremodel has a specific meaning and does specific things. Thecomponents insidea Bounded Context are context specific and semantically motivated.
Vaughn Vernon 《领域驱动设计精粹》
限界上下文是一种语义上的上下文边界。意思是在这个边界里的软件模型组件都有它特定的含义并且做特定的事。一个限界上下文内的组件都是上下文特定的并且语义明确的。

就好像零售系统里的售卖机，在不同用户角色眼里就是不同：

• 库存被消耗的有需要被及时补充的商品容器
• 吞钱吐商品的机器

所以要明确对象所处上下文环境，即限界上下文。

1.1 为何需要限界上下文

• 自然语言具有模糊性

• 同一个事物面向不同场景有不同模型

• 软件系统需要分解模型，以控制复杂性

• 限界上下文是分工的单位

  天然高内聚，低耦合。

之前说过分工依据子域，这里为啥又说基于限界上下文呢？理想情况下，子域和限界上下文一一对应，子域属问题空间，限界上下文属解决方案空间，二者说法并不完全冲突。建模设计过程中，限界上下文也是后于子域而显现出来的。所以前期分工的确基于子域，后期进入战术设计，就要基于限界上下文了。

2 概念

限界上下文，用以确定语义所在的领域边界。就可在统一的领域边界内用统一的语言进行交流。

限界上下文定义领域边界，以确保每个上下文含义在它特定的边界内都具有唯一含义，领域模型则存于该边界内。

封装通用语言和领域对象，提供上下文环境，保证在领域之内的一些术语、业务相关对象等（通用语言）无二义性。
这个边界定义了模型的适用范围，使团队所有成员能够明确地知道什么应该在模型中实现，不应该在模型中实现。

限定了通用语言自由使用的边界，一旦出界，含义便无法保证。
比如，同样是“订单”，不加限制，很难区分它在哪种场景。一旦定义了限界上下文，那交易上下文的“订单”和物流上下文的“订单”肯定不同。就是因为订单这个说法，在不同边界内，含义不同。

注意，子域和限界上下文不一定是一一对应的，可能在一个限界上下文中包含了多个子域，也可能在一个子域横跨了多个限界上下文。

限界上下文是在解决方案层面，所以，就可以把限界上下文看作一个独立系统。限界上下文与微服务的理念契合，每个限界上下文都可成为一个独立服务。

限界上下文是完全独立的，不会为了完成一个业务需求要跑到其他服务中去做很多事，这恰是很多微服务出问题的点，比如一个业务功能要调用很多其他系统功能。

有限界上下文，就可以把整个业务分解到不同的限界上下文中，但是，尽管我们拆分了系统，它们终究还是一个系统，免不了交互。
比如：

• 一个用户下了订单，这是在订单上下文中完成的
• 用户要去支付，这是在支付上下文中完成的

我们要通过某种途径让订单上下文的一些信息发送到支付上下文。所以，要有一种描述方式，描述不同限界上下文之间交互的方式-上下文映射图（Context Map）。
DDD 给我们提供了一些描述这种交互的方式，比如：

• 合作关系（Partnership）
• 共享内核（Shared Kernel）
• 客户-供应商（Customer-Supplier）
• 跟随者（Conformist）
• 防腐层（Anticorruption Layer）
  防腐层是最具防御性的一种关系，就是在外部模型和内部模型之间建立起一个翻译层，将外部模型转化为内部模型。但凡有可能，就要建立防腐层，将外部模型完全隔离开。
• 开放主机服务（Open Host Service）
• 发布语言（Published Language）
• 各行其道（Separate Ways）
• 大泥球（Big Ball of Mud）
  要规避

这么多交互方式，主要是为让你在头脑中仔细辨认，看看限界上下文之间到底在以怎样的方式交互。

知道不同限界上下文之间交互方式后，不同交互方式就可落地为不同协议。
常用协议如：REST API、RPC 或是 MQ， 按需选型即可。

在我们定义好不同的限界上下文，将它们之间的交互呈现出来之后，就得到了一张上下文映射图。
上下文映射图是可以帮助我们理解系统的各个部分之间，是怎样进行交互的，建立全局性认知。

3 案例

业务的通用语言也有它的业务边界。限界上下文就是用来细分领域，从而定义通用语言所在的边界。

如电商领域的商品，商品在不同阶段有不同术语：

• 销售阶段是商品
• 运输阶段则变成货物

同一个东西，由于业务领域不同，赋予了这些术语不同涵义和职责边界，这个边界就可能会成为未来微服务设计的边界。领域边界就是通过限界上下文来定义的。

4 划分限界上下文

4.1 Domain Storytelling 领域故事陈述法

就能得到如下三个限界上下文：

但好像和之前总结出来的子域并非一一对应，这是为啥呢？其实像用户域、商品域、设备域等并未消失，只是隐藏在更细致的模型里啦。毕竟讨论用户故事时，本身粒度其实都是较粗的，自然不会深挖太多细节。

4.1.1 边界特征

① 对象和对象间的单项联系

如图中红框箭头：

② 概念之间的语义差别

画图时就要注意使用不同图标代表不同的概念。

③ 活动的触发方式

比如库存计划就是定期触发，和投放就不同。那么是否要将他俩拆到两个不同限界上下文呢？可能并不一定，其实他俩还是很多相关的，可能无法直接拆到两个团队去做。

4.2 Event Storming（事件风暴法）

4.3 基于了域概念提取

适合项目初期的战略设计，快速简便的识别限界上下文。

5 子域和限界上下文

按之前操作，我们划分完了子域和限界上下文后，得到：

6 限界上下文和微服务

不管单体还是微服务，都有限界上下文，微服务只不过是限界上下文的一种实现方式，一般一个限界上下文对应一个服务。

子域还可根据需要进一步拆为子子域

如支付子域，继续拆为收款、付款子子域。拆到一定程度后，有些子子域的领域边界可能变成限界上下文的边界。

子域可能包含多个限界上下文

如理赔子域就包括报案、查勘和定损等多个限界上下文（限界上下文与理赔的子子域领域边界重合）。也有可能子域本身的边界就是限界上下文边界，如投保子域。

每个领域模型都有其对应限界上下文

领域内所有限界上下文的领域模型构成整个领域的领域模型。
理论上限界上下文就是微服务的边界。我们将限界上下文内的领域模型映射到微服务，就完成了从问题域到软件的解决方案。

限界上下文是微服务设计和拆分的主要依据。
在领域模型中，如果不考虑技术异构、团队沟通等因素，一个限界上下文理论上就可以设计为一个微服务。

7 总结

• 限界上下文是在解决方案空间对模型的分解单位
• 限界上下文的作用: 控制复杂性，便于分工协作
• 限界上下文的三种划分方法