服务序列图&上下文映射关系

C

S

限界上下文的协作关系

确认接龙付款服务序列图

事件总线

鉴权

记录用户参与接龙

员工上下文

P

店铺

接龙上下文

为店铺初始客户信息

确认接龙付款

商家账户上下文

商品

初始化店铺服务序列图

初始化店铺

商品上下文

服务序列图

处理订单创建事件

C/S模式（C 表示服务调用客户端、S 表示被调用服务端），P/S模式（P 表示消息发布者，S 表示消息订阅者）

订单已创建

鉴权上下文

为店铺初始化

订单

创建订单

所有限界上下文的协作关系

员工

在DDD战略阶段识别限界上下文的映射关系时非常有用，一般路是识别系统的所有业务用例（或业务服务），然后根据语义相关性、功能相关性识别限界上下文，再找出跨上下文的业务用例，从架构设计的技术视角绘制服务序列图，进而识别它们之间的映射关系。

客户

商家账户

获取用户鉴权信息

创建付款订单

接龙

初始化店铺自身属性

限界上下文映射关系

图中实线是服务调用关系，属于“强关系”；虚线是消息通知关系，属于“弱关系”。      通过该限界上线文映射关系可以看出：我们总共有 9 个限界上下文，其中有强依赖关系的涉及到 9 个、强依赖关系链有 9 条。分别是：接龙依赖于店铺、商品和订单，店铺依赖于平台集成，订单依赖于商品，商家账户、员工、客户依赖于鉴权，商家账户依赖于订单。9 个上下文，理论上最多有 72 条依赖链条，我们分析汇总后只有 11 条，已经是很好的设计。      基于这样的综合评估，我们认为目前的设计已经到了“可接受程度”，暂时不再做更多的优化和调整了，以避免“过度设计”。

客户上下文

店铺上下文

系统机器人

平台集成

订单上下文

增加商品销量