业务建模
导航问题
业务建模如何解决协作问题？面对具体业务问题时，应该怎样选择并持续积累建模方法？
核心观点
业务建模通过具体场景、统一语言和可检验模型，建立业务与技术共同修正业务理解的反馈机制；具体方法应按当前需要解决的协作或分析问题选择，而不是被当作互斥选项或固定阶段。
业务建模解决的协作问题
用户故事只给出角色、功能与价值，不能单独说明整体解决方案、用户旅程、业务规则和例外。业务建模把故事放回业务上下文，主要处理四类协作问题：
| 协作问题 | 建模如何介入 |
|---|---|
| 业务知识隐含在经验和语言中 | 用具体示例展开正常路径、边界与异常，使规则可以被观察和讨论 |
| 业务与技术从不同角度理解系统 | 用统一语言和模型建立双方都能使用的共同表达 |
| 团队对问题范围和概念边界存在分歧 | 让参与者围绕同一场景比较解释，并把差异落实为概念、关系或规则 |
| 错误理解直到实现或验收时才暴露 | 用场景检验模型，并让实现、测试和运营证据返回模型继续修正 |
这使业务建模既是一种模型构造活动，也是一种协同工作方式。领域驱动设计的核心思想把模型置于业务与技术协作的中心；知识消化法的核心概念和应用要点则通过模型、统一语言和提炼知识的循环维持这种协作。
场景—模型反馈循环
- 展开场景：用具体示例探索正常路径、边界与异常，必要时以 Given / When / Then 表达条件、行为与结果。
- 提炼模型：从场景中识别概念、关系和规则，以模型压缩团队当前的业务理解。
- 形成统一语言：业务、产品和工程使用同一组概念继续描述需求、解释行为和判断变化。
- 相互检验：模型若不能解释场景，说明概念或关系仍有缺口；场景若不能用统一语言表达，说明团队尚未形成共同理解。
- 接受下游反馈：实现、测试、验收和运营暴露的新证据返回场景与模型，必要时也返回用户故事修正角色、价值、范围或验收条件。
这构成功能方案反馈循环的主要机制：
业务问题 → 场景共创 → 统一语言与模型 → 方法选择 → 架构与任务分解 → 实现反馈返回场景和模型
建模方法的层级与谱系
这些方法不是一组彼此并列的工具，而是从不同建模入口形成的谱系：
- 从对象模型展开业务维度
- 通过事件发现领域概念
- 从合同权责分析业务系统
- 履约建模法（8X Flow）用合同、履约、凭证和违约组织业务逻辑；它由四色建模演进而来，也可以借用事件建模的时间线和工作坊形式，但不只是事件建模的一个并列变体。
按问题选择具体方法
下表只比较能够直接用于当前问题的具体方法；事件建模法作为上位元方法，不再与其具体变体并列。
| 当前需要解决的问题 | 具体方法 | 优先选择的条件 | 产物、检验方式与局限 |
|---|---|---|---|
| 让对象模型直接呈现流程、功能与对象协作 | 催化剂建模法 | 流程较简单，或处于复杂项目的早期探索 | 交互、角色与 uses 关系；检查业务方能否从模型读出流程，复杂流程下粒度可能过粗 |
| 从参与者目标发现领域概念，又不把交互放入正式模型 | 角色—目标—实体法 | 希望保留较纯净、容易映射到实现的对象模型 | 角色—目标—实体表与领域模型；检查业务方能否解释目标如何由模型支撑 |
| 让不同参与者共同暴露业务流程和语言分歧 | 事件风暴法 | 跨角色共创比稳定分析约束更重要 | 事件、命令、策略、聚合和阅读模型；共创能力强，但收敛质量依赖主持逻辑 |
| 用经营逻辑收敛事件并推导业务脊梁 | 四色建模法 | 存在现金、KPI、凭证或审计追溯要求 | 可追溯的凭证流、角色与参与方；检查关键数据和权责能否沿凭证链追溯 |
| 分析合同、履约、违约、业务异步状态和变化点 | 履约建模法（8X Flow） | 业务受合同、协议、绩效承诺或跨主体协作约束 | 合同、履约、渠道和领域上下文；检查正常与违约责任链、凭证来源和边界是否闭合 |
这些方法可以组合使用，但不构成固定阶段：事件风暴提供参与和发散，四色建模提供收敛逻辑与凭证追溯，8X Flow 为合同、履约、异常和变化点提供结构。催化剂建模与角色—目标—实体法适合直接从对象模型展开业务维度；复杂流程则可以转向事件建模。无论采用哪种组合，最终都要回到具体场景检查模型是否真正解释了业务。
从共同模型到实现
业务建模把“需要解决什么问题”推进为“业务如何运作、解决方案必须尊重哪些规则”，但这些知识仍不是实现任务：
- 领域建模可以继续探索领域问题，并把业务理解落实到对象模型和设计概念中。
- 架构与任务分解把场景与模型映射为组件职责、交互关系、工作步骤和验证边界。
- TDD 与结对编程、产品验收和DevOps 与运营反馈产生实现、验收与运行证据；它们若否定当前理解，应返回相应场景、模型或用户故事，而不是在错误边界内继续实现。
API、微服务、弹性边界和 SaaS 等属于模型落地时的具体架构问题。本地图只保留它们与业务建模的交接边界，详细方法应由相应知识卡或地图展开。
持续积累建模方法
新增方法进入本地图时，应至少能够说明：
- 它解决哪一种协作或分析问题；
- 它需要什么输入、参与者和前置判断；
- 它通过什么步骤改变团队的理解；
- 它产生什么模型、语言、场景或证据；
- 它怎样回到具体业务接受检验；
- 它如何进入实现，以及在哪些条件下不适用。
只有名称相似、阶段相邻或使用相同图形，不足以证明两种方法具有关系。地图只保留能够帮助选择、组合或检验方法的稳定连接，具体步骤、案例和变体留在各方法卡中。
阅读路径
- 理解协作机制：用户故事 → 统一语言 → 知识消化法的核心概念和应用要点 → 提炼知识的循环的核心概念和应用要点。
- 选择建模方法：先识别当前协作或分析问题，再从上表进入对应方法；不要先选工具再寻找问题。
- 进入实现与反馈：领域建模 → 架构与任务分解 → TDD 与结对编程 → 产品验收 → DevOps 与运营反馈。
⚠ Switch to EXCALIDRAW VIEW in the MORE OPTIONS menu of this document. ⚠ You can decompress Drawing data with the command palette: ‘Decompress current Excalidraw file’. For more info check in plugin settings under ‘Saving’
Excalidraw Data
Text Elements
场景展开模型，模型反过来解释场景
具体场景
概念与关系
可检验模型
模型解释不了例外，就回到场景
Embedded Files
2bf81e21806cddc35caaf0bd4fcdcb925b901660: Icon - 对话, 沟通, 协商, 参与方, 客户, 交付团队, 功能方案, conversation - Flaticon.excalidraw
fe434a10ed880a4f05f6332449dafe0f386fdaa4: Icon - 关系树, 层级图, 目录, 节点, 分支, 知识地图, hierarchy, relationship tree - Flaticon.excalidraw
b6e093b4f990541785a72fbf2b0a3a355b88ada6: Icon - 折叠地图, 业务地图, 范围, 路线, folded business map - Own.excalidraw