DDD上下文映射图怎么画？把限界上下文和团队协作关系分清楚

DDD上下文映射图画的是不同业务模型的边界，以及它们之间怎样合作、交换含义。先确定每个限界上下文负责哪些规则，再连接上下游，说明谁影响谁、交换什么、谁负责翻译。它不等于系统部署图，也不是把业务流程的每一步都拆成一个微服务。

可以用Boardmix架构图工具把上下文边界、团队责任和关系说明放在同一张图上。本文用企业培训业务贯穿：同样叫“课程”，目录、报名和学习团队心里可能是三个不同的对象。

同一个词出现不同规则，就是值得调查的边界

课程目录团队说“课程下架”，意思是不再作为商品展示；报名团队说“课程取消”，可能是某一期培训不再举办；学习团队说“课程完成”，则可能是某位学员完成了学习要求。若所有团队共用一个“课程状态”字段，下架、停班和学员完成很容易相互干扰。

这不是要求全公司统一成一种叫法。重点是每个上下文内部用词一致，跨边界时明确映射。例如报名侧传递的是“班期编号和学员名单”，学习侧据此建立学习资格，不需要把目录的展示状态也当成学员状态。

Martin Fowler对限界上下文的说明强调，大模型中的同名概念可以在不同语境下拥有不同模型。上下文地图把这些关系显式呈现出来，避免依赖口头上的“大家都懂”。

先写职责卡，再画四个候选上下文

根据上面的词义和规则，先提出四个边界候选。它们需要业务人员和研发共同确认，并不因为画了四个框就必须部署四套服务。

每张职责卡再补“谁确认规则”“谁维护模型”“当前争议”三项。团队名可以写在框外；不能直接把部门组织图变成上下文图。一个团队可能维护多个模型，某个模型也可能暂时需要多人协调，重要的是规则归属能说清楚。

如果还没有足够业务材料，可先做事件风暴工作坊，找到事件、规则和分歧。事件风暴帮助理解发生了什么；上下文映射进一步决定哪些含义应该在同一模型里，以及跨边界怎样衔接。

连线写清上下游，不用一根箭头表达所有意思

本例用U表示上游、D表示下游，箭头统一从U指向D，表示模型或契约影响方向，不表示HTTP请求方向，也不表示业务先后顺序。下游调用上游接口时，请求方向可能与这根箭头相反。图例要写在图内，不能让读者靠猜。

第一条可以按“客户—供应者”关系讨论，因为下游需求会进入上游的计划和契约协商。不是所有调用关系都自动属于这种模式：如果上游完全不接受协商，就应如实记录这种约束，再决定下游怎样适配。外部财务账套那条关系，则重点讨论防腐层。

防腐层的作用是隔离语义差异。它可以在应用内部实现，也可能是单独组件；不是必须购买或部署一种新产品。微软的防腐层模式说明指出，其核心是翻译外部模型，防止外部语义限制内部设计。增加这层也会带来维护和运行成本，因此先说明需要保护什么，不为每条线机械加一个ACL标签。

把最危险的一条关系展开：状态相似，不代表含义相同

设外部财务账套将某条凭证标记为“已入账”。企业结算不能直接把它翻译成“客户已付款”，因为入账与回款不是同一件事。下面是需要业务确认的映射草案：

这份表还不是财务规则的批准文件。企业结算负责人需要确认含义，技术负责人负责把规则落实到接口和测试。图里至少记录契约位置、负责团队、版本，以及变更后由谁通知谁；不要只留“数据同步”四个字。

同样，目录下架后，历史班期和已报名学员怎么办，需要单独明确。不能因为目录系统改了状态，便自动删除学习资格。反过来，学员完成学习也不应自动触发退款或费用核销。用这几条变化走查边界，常能发现原先隐含的跨团队决定。

在Boardmix中先画关系，再补可验证的说明

1. 摆放上下文边界。四个内部上下文各用一个大框，外部财务账套放在边缘并标“外部”。框内只放核心模型和规则，不塞数据库、服务器或所有页面。
2. 按表连接四条关系。端点标U/D，线上写交换内容；在企业结算边界内标出“财务状态翻译”。用文字说明关系，不仅靠颜色。
3. 展开一条待讨论关系。把财务状态映射表放到该连线旁，连到负责人和契约记录。其余详细字段保留在正式接口文档中。
4. 走查变化。依次问课程下架、班期取消、名单修订、财务新增状态会影响谁；凡是图上找不到负责人的地方，就留下具体待办。

评审时不要以框和线的数量衡量完整度。能否解释一个词在不同地方的含义、哪一方有权改变规则，以及另一方怎样消化变化，更重要。若两处始终共享同一套规则且变化紧密相连，边界可能需要合并；若一个框里同词冲突不断，则要重新检查是否混进了不同模型。

上下文确定后，再讨论服务与应用怎样实现。微软的领域分析指南也把领域分析、上下文定义和服务识别分成相互关联的步骤。上下文并不天然与部署单元一一对应，图画完不能直接变成服务拆分清单。

可以在Boardmix整理自己的上下文地图，先挑一个最常争论的词，写出它在各团队中的含义，再画边界。让连线背后的责任和翻译规则清楚，图才有助于下一次真实的接口变更与业务讨论。