在完成了限界上下文的识别（也就是系统“最粗粒度”的模块划分）后，我们需要对这些上下文之间的协作关系进行分析——即“限界上下文关系映射”。也只有在完成上下文关系映射后，我们才能真正的判定自己所做出的“限界上下文识别”是否真的达到了自己想要的“低耦合、高内聚”的目标。因为，通过“限界上下文映射”我们就能够看到：
- 这些上下文之间有哪些协作关系？
- 这些关系是强关联还是弱关联？
关于“限界上下文识别”和“限界上下文关系映射”，我认为这是 DDD 战略设计中最重要的部分，甚至可以说：这两个工作将决定了微服务切分是否有效的关键因素！
但是，肯定会有人说：限界上下文不用 DDD，我凭直觉就能识别出来。我的回答是：是的，你貌似可以！但更重要的是限界上下文的关系映射，这将决定做微服务拆分后、这些微服务之间是怎样做到“高内聚、低耦合”的。如果你不用 DDD 战略设计，我可以很负责任的告诉你：你将来的“微服务”之间的调用关系一定会变得无法控制！
在我实际工作中接触的某大型国企 IT 系统中，所谓业务中台上千万行代码，部署在十多个微服务中心，而 80%以上的外围接口调用、或前端界面服务请求，都要从十个以上的微服务中心全部走一遍！这是不是很可怕的灾难？系统的高可用性、业务需求的快速响应还有什么保障可言？
所以说：掌握好 DDD 战略设计，几乎是做好微服务设计必不可少的前提！不懂得 DDD，你做的“微服务拆分”可能还不如不拆分，单体应用可能更适合你！
在本节内容中，除了搞定限界上下文的映射之外，我还将对系统分层架构进行设计，并在最终给出项目组可直接用于开发的代码框架结构。
需要特别说明的是：在写到这篇的过程中，我反复和多位业界大拿请教，大家普遍认为我前面第三篇中业务子域的分类上“核心子域”太多了。我经过再三考虑，将“核心子域”进行了调整，这将影响到本篇关于系统分层结构的设计，您可以跳回到第三篇重新看下“业务子域识别与分类”这一小段。这里再次重申下：您在阅读中发现我的任何不妥之处 ，可随时与我交流，我发现不妥之处一定认真思考改进，感谢您的支持！
01限界上下文映射
1跨上下文用例识别
为了识别限界上下文之间的映射关系，我们需要对跨上下文的业务用例（也叫业务服务），从架构设计的技术视角绘制服务序列图，进而识别它们之间的映射关系。
首先，第一步，我们识别出所有的跨限界上下文的业务用例。在识别某个业务用例是否跨限界上下文时，一定要注意两个基本事实：1）其实大部分业务用例都是从“群买菜”小程序前端界面发起的，前端与服务端的交互，不算跨限界上下文；2）限界上下文提供的是服务端的业务服务，跨限界上下文一定要是服务端逻辑的相互关系。
关于如何识别“服务端的跨限界上下文”业务逻辑，我认为需要逐个分析前面罗列的所有业务用例，从如下两个角度筛选：
初步分析业务用例内部的逻辑，看是否需要多个上下文来承担职责。如果是，则需将该用例纳入分析范围；
分析业务用例图中的被包含的“子用例”，看是否存在上下文包含了被归类到别的上下文的情况。如果是，则需将该用例纳入分析范围；为此，识别结果如下图罗列：
需要说明的是：有几个用例看起来好像是跨上下文的，其实不是。分别说明如下：
1. “确认购买并付款”、“创建订单预支付”、“完成订单支付”、“补收客户货款”、“退客户货款”，这几个用例其实是订单上下文和支付系统之间的关系。考虑到我们的系统上下文设计，支付系统其实不是我们目标系统的工作范围，故这里不纳入范围。
2. “后台查询店铺商品”、“后台浏览店铺订单列表”、“管理店铺客户信息”、“管理店铺员工”、“开通店铺加盟并设置分成政策”、“添加品牌店铺到加盟列表”，看起来每个用例的名称上都涉及到 2 个限界上下文、并都跟“店铺”上下文发生关系，其实它们只是需要店铺 ID，并没有与店铺上下文发现任何业务交互，故实际上不作为“跨上下文”的用例来对待。
其次，这些业务用例中，从跨上下文协作关系角度来看，其中有些用例画服务序列图是会出现重复的，我们需要识别出来：
1. “创建新店铺”、“编辑店铺信息”，会用到短信验证码验证手机号，故都属于跨店铺、平台集成两个限界上下文的，且交互逻辑一致，故重复。
2. “加商品到购物车”、“选购接龙商品到购物车”，其实都是涉及到订单和商品两个限界上下文的相同交互关系，故重复。
3. “创建接龙活动”、“编辑接龙活动”，这两个业务用例的操作序列，从跨上下文协作关系角度来看也是完全一样的，只是后者需加载原有“接龙”上下文内部已持久化的信息、前者不用。
4. “创建付款订单”是“确认接龙付款”的子用例，故只需要保留“确认接龙付款”即可。
5. “添加品牌店铺到加盟列表”、“从加盟列表删除品牌店铺”，这两个业务用例都是涉及到店铺和加盟两个上下文的关系，并且都是获取店铺相关信息、并将店铺信息传输给加盟上下文处理，故重复。
最终，我们确定下来，被用来绘制服务序列图，进而确定各上下文协作关系的业务用例罗列如下图：
2基于跨上下文用例映射上下文关系
我们接下来的工作，就是要对这些业务用例，逐个进行技术分析，设计出服务序列图，然后根据服务序列图确定限界上下文的关系映射。
创建新店铺
创建新店铺涉及到手机号短信验证，故需要跨店铺和平台集成两个上下文。服务序列图如下：
基于该服务序列图识别出“店铺”和“平台集成”上下文关系如图（C 表示服务调用客户端、S 表示被调用服务端，以下同。DDD 标准方法中一般用“上下游关系”、及诸如“开发主机服务 OHS”等方式表达，但我认为那是废话，并没有清晰的表达强弱关联，故不在这里采用）：
初始化店铺默认选项
根据产品 UI 原型的设计方案，新店铺创建后，系统机器人需要基于异步事件，对店铺的相关选项立即进行初始化：
1. 店铺默认门头图片（UI 允许创建人未设置门头图片）；
2. 店铺是否开通订单短信提醒（随着业务发展可能会调整，故不放在创建店铺时设定）；
3. 店铺的第一个员工（就是创建人自己）；
4. 店铺默认的加盟分销政策（随着业务发展可能会调整，故不放在创建店铺时设定）；
5. 店铺的首个接龙地点（详见产品 UI 原型，店铺接龙支持多个地点，但首个地点就是店铺地址）；
6. 创建商家及商家账户（如果是创建人的第一家店铺）；
7. 店铺默认商品分类（系统规则会按季节调整）；
8. 店铺默认的商品搜索热词（系统后台会不定期根据某种策略更新）；
这些默认选项，涉及到“店铺”、“员工”、“商品”、“接龙”、“商家账户”、“鉴权”共 6 个上下文的协作。服务序列图涉及如下：
根据该服务序列图，我们得出这 6 个限界上下文的协作关系如下图：
从上图的上下文依赖关系中，看到店铺对员工、商品、接龙、商家账户 4 个上下文产生了调用关系依赖，这是不合理的。因为从业务角度来说，其实是后 4 者依赖于店铺的存在而存在，而不是反过来。为此，我们做这样的调整：
1. 采用消息发布者/订阅者模式，让后 4 者依赖店铺上下文发布的“店铺已创建”消息；
2. 去掉“接龙”上下文对店铺首个接龙地点初始化的逻辑。本质上，仔细分析产品 UI 界面设计的要去，我们发现这其实是“群买菜小程序”在展示创建接龙活动的前端界面时，需调用“店铺”上下文服务来获取的信息：如果所选择店铺已经有接龙地址，则返回已有的接龙地址列表供选择；如果该店铺尚无首个接龙地址，则返回店铺地址作为默认接龙地址。
经过修改后的服务序列图如下：
根据该服务序列图，我们修改上下文的协作关系如下图（P 表示消息发布者，S 表示消息订阅者，下同）：
加商品到购物车
客户浏览店铺商品，选中感兴趣的商品到购物车，以便后续的购买结算。考虑到添加商品到购物车中去的“时间”特殊性：我们需要在客户将商品加入到购物车时，为商品创建“快照”，以避免商品信息在后面被编辑修改（比如改了图片或描述、尤其是价格）时，影响到对客户的购买承诺。
为此，该业务用例（服务）就涉及到“订单”和“商品”两个上下文，服务序列图设计如下：
该序列图展示出订单和商品的上下文关系如图：
发送订单提醒
“发送订单提醒”需要在订单上下文中发起、“通知”上下文中发送通知，故涉及“订单”和“通知”两个上下文。该用例服务序列图如下：
考虑到订单消息提醒是没有副作用的、而且也不需要保证必须成功，故采用消息发布者/订阅者模式比较合适。也就是得到如下所示的“订单”和“通知”上下文的映射关系：
创建接龙活动
与“加商品到购物车”用例类似，商家在创建接龙活动、添加商品到接龙中去时也存在“时间”特殊性，需要为商品创建“快照”，以避免商品在后面被编辑修改（比如改了图片或描述、尤其是价格）时，影响到接龙活动的开展。为此，该业务用例（服务）就涉及到“接龙”和“商品”两个上下文，服务序列图设计如下：
该序列图展示出接龙和商品的上下文关系如图：
浏览我的接龙
按照产品 UI 设计文档，接龙只能在店铺下存在。而“浏览我的接龙”实际上是“浏览我被授权操作的所有店铺发布的、或其被授权店铺所加盟品牌店铺发布的、或我参与的”的所有接龙。故该用例涉及到“接龙”、“店铺”两个上下文，服务序列图如下：
