DDD 实战 (5)：限界上下文映射和系统分层架构

在完成了限界上下文的识别（也就是系统“最粗粒度”的模块划分）后，我们需要对这些上下文之间的协作关系进行分析——即“限界上下文关系映射”。也只有在完成上下文关系映射后，我们才能真正的判定自己所做出的“限界上下文识别”是否真的达到了自己想要的“低耦合、高内聚”的目标。因为，通过“限界上下文映射”我们就能够看到：1）这些上下文之间有哪些协作关系？2）这些关系是强关联还是弱关联？

关于“限界上下文识别”和“限界上下文关系映射”，我认为这是 DDD 战略设计中最重要的部分，甚至可以说：这两个工作将决定了微服务切分是否有效的关键因素！

但是，肯定会有人说：限界上下文不用 DDD，我凭直觉就能识别出来。我的回答是：是的，你貌似可以！但更重要的是限界上下文的关系映射，这将决定做微服务拆分后、这些微服务之间是怎样做到“高内聚、低耦合”的。如果你不用 DDD 战略设计，我可以很负责任的告诉你：你将来的“微服务”之间的调用关系一定会变得无法控制！

在我实际工作中接触的某大型国企 IT 系统中，所谓业务中台上千万行代码，部署在十多个微服务中心，而 80%以上的外围接口调用、或前端界面服务请求，都要从十个以上的微服务中心全部走一遍！这是不是很可怕的灾难？系统的高可用性、业务需求的快速响应还有什么保障可言？

所以说：掌握好 DDD 战略设计，几乎是做好微服务设计必不可少的前提！不懂得 DDD，你做的“微服务拆分”可能还不如不拆分，单体应用可能更适合你！

在本节内容中，除了搞定限界上下文的映射之外，我还将对系统分层架构进行设计，并在最终给出项目组可直接用于开发的代码框架结构。

需要特别说明的是：在写到这篇的过程中，我反复和多位业界大拿请教，大家普遍认为我前面第三篇中业务子域的分类上“核心子域”太多了。我经过再三考虑，将“核心子域”进行了调整，这将影响到本篇关于系统分层结构的设计，您可以跳回到第三篇重新看下“业务子域识别与分类”这一小段。这里再次重申下：您在阅读中发现我的任何不妥之处 ，可随时与我交流，我发现不妥之处一定认真思考改进，感谢您的支持！

4. 限界上下文映射

4.1 跨上下文用例识别

为了识别限界上下文之间的映射关系，我们需要对跨上下文的业务用例（也叫业务服务），从架构设计的技术视角绘制服务序列图，进而识别它们之间的映射关系。

首先，第一步，我们识别出所有的跨限界上下文的业务用例。在识别某个业务用例是否跨限界上下文时，一定要注意两个基本事实：1）其实大部分业务用例都是从“群买菜”小程序前端界面发起的，前端与服务端的交互，不算跨限界上下文；2）限界上下文提供的是服务端的业务服务，跨限界上下文一定要是服务端逻辑的相互关系。

关于如何识别“服务端的跨限界上下文”业务逻辑，我认为需要逐个分析前面罗列的所有业务用例，从如下两个角度筛选：

• 初步分析业务用例内部的逻辑，看是否需要多个上下文来承担职责。如果是，则需将该用例纳入分析范围；

• 分析业务用例图中的被包含的“子用例”，看是否存在上下文包含了被归类到别的上下文的情况。如果是，则需将该用例纳入分析范围；

为此，识别结果如下图罗列：

需要说明的是：有几个用例看起来好像是跨上下文的，其实不是。分别说明如下：

1. “确认购买并付款”、“创建订单预支付”、“完成订单支付”、“补收客户货款”、“退客户货款”，这几个用例其实是订单上下文和支付系统之间的关系。考虑到我们的系统上下文设计，支付系统其实不是我们目标系统的工作范围，故这里不纳入范围。

2. “后台查询店铺商品”、“后台浏览店铺订单列表”、“管理店铺客户信息”、“管理店铺员工”、“开通店铺加盟并设置分成政策”、“添加品牌店铺到加盟列表”，看起来每个用例的名称上都涉及到 2 个限界上下文、并都跟“店铺”上下文发生关系，其实它们只是需要店铺 ID，并没有与店铺上下文发现任何业务交互，故实际上不作为“跨上下文”的用例来对待。

其次，这些业务用例中，从跨上下文协作关系角度来看，其中有些用例画服务序列图是会出现重复的，我们需要识别出来：

1. “创建新店铺”、“编辑店铺信息”，会用到短信验证码验证手机号，故都属于跨店铺、平台集成两个限界上下文的，且交互逻辑一致，故重复。

2. “加商品到购物车”、“选购接龙商品到购物车”，其实都是涉及到订单和商品两个限界上下文的相同交互关系，故重复。

3. “创建接龙活动”、“编辑接龙活动”，这两个业务用例的操作序列，从跨上下文协作关系角度来看也是完全一样的，只是后者需加载原有“接龙”上下文内部已持久化的信息、前者不用。

4. “创建付款订单”是“确认接龙付款”的子用例，故只需要保留“确认接龙付款”即可。

5. “添加品牌店铺到加盟列表”、“从加盟列表删除品牌店铺”，这两个业务用例都是涉及到店铺和加盟两个上下文的关系，并且都是获取店铺相关信息、并将店铺信息传输给加盟上下文处理，故重复。