第4章 功能边界划分的标准操作流程
功能边界划分是系统架构设计与原型评审之间的关键衔接环节。本章提供一套标准操作流程，通过四个连续子阶段——拆解业务域、识别实体与交互、定义接口与依赖、绘制边界图——将模糊的业务需求转化为可评审的边界视图。该流程适用于新建系统模块拆分、遗留系统服务化解耦以及多个团队协同的需求导入阶段。
适用场景
- 大型需求文档（通常超过50个用户故事）需要拆分为功能域时。
- 跨团队/跨中台协作，需要明确各方交付边界与接口契约时。
- 原型设计前，需要为UI/UX团队提供清晰的功能领域地图。
前置条件
- 已完成业务调研与需求收集，产出《业务需求说明书》或《用户故事地图》。
- 已建立统一术语表，消除关键业务概念歧义。
- 参与角色（业务分析、系统架构、产品经理）已就位。
操作步骤
每个阶段均有明确的输入、输出、责任角色和关键动作，如下表所示。
| 步骤 | 输入 | 输出 | 责任角色 | 关键动作 |
|---|---|---|---|---|
| 拆解业务域 | 业务需求说明书、用户故事地图 | 业务域列表、SUB-DOMAIN字典 | 业务分析师 + 产品经理 | 按业务流程主线划分，每人认领1~2个子域 |
| 识别实体与交互 | 业务域列表、领域术语表 | 实体清单、交互矩阵 | 领域专家 + 架构师 | 为每个子域提取核心Entity及跨域消息流 |
| 定义接口与依赖 | 交互矩阵、实体清单 | 接口契约列表、依赖关系图 | 系统架构师 + 接口负责人 | 明确API/Event/DB共享表，标记强/弱依赖 |
| 绘制边界图 | 接口契约、依赖关系图 | 边界视图 boundary-map.png/.svg |
架构师 + UX设计师 | 使用Bounded Context表示法，标注上下游 |
步骤1：拆解业务域
以业务流程为主线，将需求按功能聚合拆分为若干独立的Sub-Domain。拆分遵循高内聚低耦合原则：每个域内部的功能必须围绕同一业务目标，域间交互尽量少。
建议：使用「事件风暴（Event Storming）」工作坊，用橙色便利贴表示事件，蓝色表示命令，快速形成域边界候选列表。
步骤2：识别实体与交互
针对每个Sub-Domain，提取核心业务实体（Entity / Aggregate）。识别跨域的Event或Message交互，形成实体-交互矩阵，矩阵行与列均为域，单元格标记流量方向与频率。
步骤3：定义接口与依赖
基于交互矩阵，为每个跨域调用定义接口契约。接口包括REST API、异步消息Topic/Queue、共享数据库表等。同时标记依赖粒度：强依赖（同步阻塞）和弱依赖（异步最终一致）。
示例：用户域 -> 订单域
接口：POST /api/v1/orders (同步强依赖)
契约参数：userId, productId, quantity
错误处理：400 BadRequest / 503 ServiceUnavailable步骤4：绘制边界图
使用Bounded Context图符将上述成果可视化。上下文边界用虚线框表示，每个子域为一个矩形，内部列出核心实体。跨域连线标注接口ID和依赖强度。推荐使用PlantUML / Draw.io协作编辑。
⚡ 验收检查：边界图中每个上下文必须且仅能由一个团队负责；所有跨域连线必须对应已定义的接口契约，不漏不重。
输入输出物清单
| 物名称 | 类型 | 描述 | 生产者 |
|---|---|---|---|
| Sub-Domain字典 | 数据表 | 子域编号、名称、负责人、关联业务线 | 业务分析师 |
| 实体-交互矩阵 | 二维表 | 行=源域，列=目标域，单元格记录协议/频率 | 领域专家 |
| 接口契约清单 | 数据表/OpenAPI | 接口路径、方法、参数、错误码、SLA | 架构师 |
| 边界视图 | 矢量图 | 包含上下文、实体、接口连线的可视化图 | 架构师+UX |
责任边界
- 产品经理：确保业务域划分与产品路线图一致，不会遗漏核心功能。
- 业务分析师：主导域拆解和实体识别，保证业务语义正确。
- 系统架构师：接口定义与依赖管理，承担技术可行性及性能风险。
- UX设计师：参与边界图绘制，确保原型设计范围与域边界对齐。
记录材料
每次边界划分会议应产出并归档以下材料：
- 会议纪要（含参会人员、决策记录）
- Sub-Domain字典 Excel/CSV
- 实体-交互矩阵截图
- 接口契约文档（OpenAPI/Swagger或Markdown表）
- 最终版边界视图（SVG/PNG）
异常处理
常见异常1：业务域高度耦合，无法清晰拆解
—— 引入事件风暴或用户故事映射，重新梳理核心流程；必要时引入“防腐层（Anti-Corruption Layer）”作为过渡边界。
—— 引入事件风暴或用户故事映射，重新梳理核心流程；必要时引入“防腐层（Anti-Corruption Layer）”作为过渡边界。
常见异常2：实体识别遗漏，导致接口定义被动补丁
—— 强制推行「两次实体走查」：第一次由领域专家独立提取，第二次交叉评审；列入实体清单checklist。
—— 强制推行「两次实体走查」：第一次由领域专家独立提取，第二次交叉评审；列入实体清单checklist。
常见异常3：依赖关系图出现环形依赖
—— 使用Dependency Structure Matrix（DSM）检测环，通过引入事件驱动或聚合层打破循环。
—— 使用Dependency Structure Matrix（DSM）检测环，通过引入事件驱动或聚合层打破循环。
验收标准
- 每个Sub-Domain有唯一负责人，且定义在字典中。
- 实体-交互矩阵中，每个跨域交互至少对应一条接口契约。
- 边界图上的所有连线均正确标注接口ID和依赖强度。
- 无环形依赖，且每一层的依赖方向清晰（上层→下层，不得反向）。
- 所有输出物通过团队评审并签字确认。