从流程抽象出领域对象
目录
这是一个非常成熟、也非常现实的建模问题。
相比事件风暴，“基于流程框架抽象业务对象”更贴近大多数组织的真实起点，但如果方法不当，极易把流程对象误当成领域对象。下面我将给出一套可控、不走偏的流程抽象法，明确告诉你：
如何从流程出发，而不是被流程绑架，最终仍然抽象出“正确的业务对象”。
一、先给出结论（避免走弯路）
流程不是领域对象的来源，而是“探针”。
流程的作用，是暴露业务责任、状态与决策点，
而不是直接生成对象。
如果你在流程图里“看到什么就建什么对象”，那得到的一定是：
- 审批对象
- 流转对象
- 任务对象
——这些几乎都不是领域对象。
二、流程抽象的正确前提：选对流程层级
在开始前，必须明确：
你抽象的是“业务流程”，不是“操作流程”。
正确层级的流程特征
- 面向业务目标（而非系统步骤）
- 包含决策与状态变化
- 能被业务人员完整讲清
例如：
- ❌ 提交表单 → 校验 → 写库
- ✅ 报价生成 → 客户确认 → 报价生效
三、从流程到对象的总体路径图
业务流程
↓
关键业务阶段（Stage）
↓
阶段前后状态变化
↓
承担状态的业务对象
↓
对象必须守护的不变量
对象永远是“承担状态”的那个东西。
四、步骤一：把流程切成“业务阶段”，而不是节点
这是最关键的一步。
错误切法（系统节点）
- 调用服务
- 人工审批
- 推送消息
正确切法（业务阶段）
- 报价准备阶段
- 报价承诺阶段
- 履约阶段
- 结算完成阶段
判断标准：
阶段切换时，业务语义是否发生了不可逆变化？
如果是 → 合法阶段。
五、步骤二：观察“阶段切换”前后，谁变了
对每一个阶段转换，问：
切换前后，什么东西“不再一样了”？
例如：
- 报价从“可修改” → “不可修改”
- 订单从“可取消” → “必须履约”
接着问：
这个变化，是发生在谁身上？
📌 这个“谁”，就是领域对象的强候选。
六、步骤三：把“人 / 系统”从流程中剥离
流程里一定会出现：
- 销售提交
- 经理审批
- 系统自动执行
⚠️ 这些不是领域对象，而是触发者。
你要做的是：
- 把“谁做”移除
- 只保留“业务世界发生了什么变化”
例如：
销售提交报价
→ 报价进入待确认状态
七、步骤四：用“状态连续性”验证对象是否成立
一个合法的领域对象，必须满足：
在多个流程阶段中，始终是“同一个东西”
例如：
- 报价从创建 → 锁定 → 接受
始终是“这份报价”
如果：
- 每个阶段都新建一个“任务对象”
- 或用流程实例来承载状态
👉 那你建的是流程对象，不是领域对象
八、步骤五：逼出不变量（流程抽象的生死线）
现在问最关键的问题：
如果我绕开流程，直接调用系统操作，这个规则还能被保证吗？
如果不能：
- 说明你把规则绑在流程上了
- 对象抽象是失败的
正确的情况是：
- 无论走哪条流程
- 对象都会拒绝非法状态转换
示例
流程规则：
- 必须经理审批后才能确认订单
领域不变量：
- 未审批通过的订单不能被确认
审批流程可以变：
- 自动审批
- 人工审批
- AI 审批
但不变量不变。
九、典型反模式（你一定见过）
1️⃣ 把流程实例当领域对象
- ApprovalFlow
- OrderProcess
- FulfillmentTask
👉 这些应该是：
- Workflow
- Application Service
- Orchestration
2️⃣ 用“步骤编号”表示状态
- Step1 / Step2 / Step3
👉 这是流程状态，不是业务状态。
3️⃣ 对象只在某一步“有用”
如果一个对象：
- 只在流程的某个节点存在
- 流程一走完就没意义
👉 它不是领域对象。
十、流程抽象 vs 事件风暴的本质差异（高级视角）
| 维度 | 流程抽象 | 事件风暴 |
|---|---|---|
| 起点 | How | What |
| 易犯错误 | 流程对象化 | 事件碎片化 |
| 适合场景 | 强监管、强审批 | 高复杂、强变化 |
| 成功关键 | 强行剥离流程 | 强行逼出不变量 |
流程抽象要成功，难度反而更高。
十一、一句话给架构师的总结
通过流程抽象领域对象的唯一正确方式，是：
把流程当成显影液，用它显现“谁在长期承担业务状态与不变量”，
然后毫不犹豫地把流程本身扔掉。
如果你愿意，下一步我可以：
- 用你熟悉的 销售 / 报价 / 订单 / 履约流程，完整示范一次“流程 → 对象 → 不变量”的建模；
- 或帮你对比：同一业务，用流程抽象 vs 事件风暴，最终对象哪里会不一样。
浙公网安备 33010602011771号