4. 模块边界识别方法：业务能力分析法、子域划分法（核心域/支撑域/通用域）、事件风暴工作坊
模块边界的准确识别是微服务拆分与领域驱动设计（DDD）落地的核心难点。错误的边界会导致服务间过度耦合、数据一致性难以保障、以及后续安全权限模型的混乱。本节将系统讲解三种业界主流的边界识别方法，帮助架构师在不同阶段选择最合适的分析工具。
4.1 业务能力分析法（Business Capability Analysis）
业务能力分析法从企业战略与业务职能出发，将组织所能提供的业务价值拆解为独立的、可组合的能力单元。该方法不关注技术实现，而是聚焦于“业务做什么”。
适用场景： 企业级架构规划初期、中台战略设计、组织架构与系统架构对齐。
4.1.1 核心步骤
- 识别一级能力域： 从企业价值链出发，识别如“客户管理”、“订单履约”、“产品创新”、“财务核算”等顶级能力。
- 逐层分解： 将一级能力域分解为二级、三级子能力，直到每个子能力具备明确的业务输入、输出和度量指标。
- 能力分组与映射： 将高内聚的子能力聚合为候选模块，并映射到现有的组织架构或系统清单。
- 边界判定： 若两个子能力之间存在频繁的数据交换或强事务依赖，则考虑合并为一个模块；反之，若依赖松散，则拆分为独立模块。
4.1.2 能力矩阵示例（电商场景）
| 一级能力域 | 二级能力 | 三级能力 | 候选模块 |
|---|---|---|---|
| 订单履约 | 订单管理 | 订单创建、订单修改、订单取消 | 订单服务 |
| 库存分配 | 库存预占、库存释放、库存查询 | 库存服务 | |
| 物流配送 | 运单生成、配送调度、签收确认 | 物流服务 | |
| 客户管理 | 客户信息 | 注册、认证、资料维护 | 用户服务 |
| 客户分层 | 积分计算、等级评定、权益发放 | 会员服务 |
4.2 子域划分法：核心域 / 支撑域 / 通用域
子域划分法源自领域驱动设计（DDD）的战略设计阶段。它通过评估业务子域在商业竞争中的战略价值，来决定技术投入的优先级和模块的自治程度。
核心原则： 核心域是企业的核心竞争力，必须自研并投入最优质的资源；支撑域为核心域提供必要支持，可适度外采或简化；通用域是行业通用能力，优先考虑成熟商业套件或开源方案。
4.2.1 三类子域对比
| 子域类型 | 商业价值 | 复杂度 | 技术策略 | 模块边界特征 |
|---|---|---|---|---|
| 核心域 | 高（差异化竞争优势） | 高（业务逻辑复杂、多变） | 自研、持续重构、高投入 | 强内聚、独立数据库、严格防腐层 |
| 支撑域 | 中（辅助核心业务） | 中（逻辑明确、相对稳定） | 自研或定制开发 | 依赖核心域、可接受一定耦合 |
| 通用域 | 低（行业标准能力） | 低（成熟、标准化） | 采购、开源、SaaS | 边界清晰、接口标准化、可替换 |
4.2.2 子域划分与模块边界决策树
在实际项目中，可通过以下决策路径快速判定子域归属与模块边界：
- 问题1： 该业务逻辑是否直接决定公司的市场竞争力？
→ 是：核心域，必须独立模块，严格隔离。 - 问题2： 该业务是否为核心域提供不可或缺的支撑？
→ 是：支撑域，可为核心域定制接口，但避免双向依赖。 - 问题3： 市场上是否有成熟、低成本的标准解决方案？
→ 是：通用域，封装为通用模块，通过适配层集成。
4.3 事件风暴工作坊（Event Storming Workshop）
事件风暴是一种协作式的、基于“领域事件”的建模工作坊。它通过跨职能团队（业务、产品、开发、测试）的集体讨论，快速发现业务全流程中的关键事件、命令、聚合和界限上下文，从而精准识别模块边界。
关键前提： 事件风暴需要业务专家深度参与，否则容易陷入技术细节而偏离真实业务流程。建议工作坊时长控制在 4-8 小时，并准备充足的便利贴和白板空间。
4.3.1 事件风暴中的核心元素
| 元素 | 颜色（标准） | 描述 | 示例 |
|---|---|---|---|
| 领域事件 | 橙色 | 业务中已经发生的、不可改变的事实 | “订单已创建”、“支付已成功” |
| 命令 | 蓝色 | 触发领域事件的用户意图或系统指令 | “提交订单”、“确认支付” |
| 聚合 | 黄色 | 具有完整业务一致性的实体与值对象集合 | “订单聚合”、“客户聚合” |
| 界限上下文 | 绿色（大框） | 模块的最终边界，包含一组高内聚的聚合 | “订单上下文”、“库存上下文” |
| 外部系统 | 粉色 | 与本系统交互的第三方或遗留系统 | “支付网关”、“ERP系统” |
4.3.2 工作坊实施流程
- 混沌探索（Chaotic Exploration）： 参与者自由地在时间轴上粘贴领域事件，不讨论对错，只求全面覆盖。
- 时间线整理（Timeline）： 将领域事件按业务发生的时间顺序从左到右排列，形成完整的故事线。
- 命令与角色识别： 在每个领域事件前，补充触发该事件的命令以及执行命令的角色（用户或系统）。
- 聚合发现： 将紧密关联的事件、命令和数据归并为聚合，并用黄色便利贴标识。
- 界限上下文划分： 将聚合按照业务语义和变化频率分组，用绿色大框圈出，形成候选模块（界限上下文）。
- 上下文映射： 分析界限上下文之间的关系（如合作关系、防腐层、发布语言等），确认模块间的集成方式。
4.4 三种方法的对比与选择策略
| 维度 | 业务能力分析法 | 子域划分法 | 事件风暴工作坊 |
|---|---|---|---|
| 输入 | 企业战略、组织架构、价值链 | 业务愿景、竞争分析 | 业务流程、领域专家知识 |
| 输出 | 能力域与能力组件清单 | 核心/支撑/通用域划分 | 界限上下文与聚合定义 |
| 粒度 | 粗（业务职能级） | 中（业务域级） | 细（聚合级） |
| 团队参与 | 企业架构师、业务高管 | 产品经理、技术负责人 | 跨职能全员（业务+开发+测试） |
| 耗时 | 1-2 周 | 2-3 天 | 1-2 天（工作坊） |
| 最佳使用阶段 | 顶层规划、中台设计 | 战略投资决策 | 模块详细拆分、微服务设计 |
推荐组合策略： 在大型企业架构项目中，建议先使用业务能力分析法完成顶层能力地图，再通过子域划分法确定投资优先级，最后针对核心域和关键支撑域开展事件风暴工作坊，完成模块边界的精细化落地。三种方法形成从宏观到微观的完整闭环。