生命周期、状态、动作与业务规则

本章目标：描述一条业务记录从产生到结束的全过程，并把口头经验整理成明确、可执行、可验证的规则。

1. 生命周期是什么

生命周期是一类业务对象从出现到结束会经历的完整过程。

采购申请可能经历：

草稿 → 审批中 → 待采购 → 采购中 → 已完成
          ↓          ↓
        已退回      已作废

这不是为了画一张漂亮的图，而是为了回答：

• 当前记录处于什么阶段；
• 现在谁负责；
• 哪些动作可以执行；
• 哪些内容可以修改；
• 下一步可能去哪里；
• 什么条件代表业务真正结束。

2. 区分事件、动作、状态和规则

概念	解释	示例
事件	发生了一件值得响应的事	用户点击提交、审批超时
动作	人或应用执行的行为	提交、同意、退回、作废
状态	业务记录当前所处阶段	草稿、审批中、待采购
规则	决定允许什么、怎样处理	总额大于 5000 元增加审批

一个常见关系是：

在某个状态发生某个事件，满足规则后执行动作，记录进入新状态。

例如：

采购申请处于“草稿”，申请人点击提交；如果至少有一行明细且金额有效，则进入“审批中”。

3. 设计状态时的原则

3.1 状态应代表业务阶段

“按钮已点击”“页面已打开”不是有管理价值的业务状态。

3.2 状态名称要能被业务人员理解

使用“待采购”比“流程完成后阶段 2”清楚。

3.3 状态之间应有明确区别

如果“已批准”和“待采购”在责任人、可执行动作和管理含义上完全相同，可能不需要两个状态。

3.4 终止状态要说清楚

“已完成”“已作废”“已拒绝”都可能结束业务，但含义和统计口径不同，不能合并成一个模糊的“结束”。

4. 建立状态与动作表

当前状态	可执行角色	允许动作	必要条件	下一状态	是否可改业务内容
草稿	申请人	保存、提交、删除草稿	提交时明细有效	审批中	可以
审批中	申请人	撤回	尚未形成不可撤回结果	草稿	不可以直接改
审批中	审批人	同意、退回、拒绝	当前任务属于本人	下一审批或待采购	不可以
已退回	申请人	修改、重新提交、作废	记录未作废	审批中或已作废	可以
待采购	行政采购员	开始采购、作废	已通过审批	采购中或已作废	只改采购信息
采购中	行政采购员	完成采购	采购结果完整	已完成	只改采购信息
已完成	有权限人员	查看	无	不再变化	不可以

这张表会直接指导表单状态、流程、权限和测试。

5. 四类业务规则

5.1 计算规则

根据已有信息得到结果：

• 行金额 = 数量 × 预计单价；
• 申请总额 = 所有行金额之和。

计算规则要说明：

• 使用哪些输入；
• 什么时候重新计算；
• 小数和四舍五入如何处理；
• 结果能否人工修改。

5.2 校验规则

判断输入是否符合要求：

• 至少填写一行采购明细；
• 数量必须大于零；
• 预计单价不能为负数；
• 用途超过一定金额时必须填写详细说明。

校验规则要同时写出用户看得懂的提示，而不是只写“校验失败”。

5.3 决策规则

根据条件选择不同处理方式：

• 总额不超过 5000 元，只需直属主管审批；
• 总额大于 5000 元，增加行政负责人审批；
• 紧急申请需要填写原因并通知行政。

5.4 权限规则

决定谁能做什么或看什么：

• 申请人只能查看自己的申请；
• 审批人只能处理分配给自己的任务；
• 行政采购员能查看所有已批准申请，但不能修改申请明细。

权限规则将在专门章节继续展开。

6. 用“条件—行为—结果”写规则

模糊规则：

大额采购需要高级审批。

明确规则：

当申请总额大于 5000 元时，在直属主管同意后，将申请交给行政负责人审批；行政负责人同意后进入待采购。总额等于 5000 元不进入该节点。

一条完整规则至少包含：

• 条件使用哪个值；
• 比较边界；
• 由谁或什么动作触发；
• 满足时做什么；
• 不满足时做什么；
• 最终业务结果；
• 用户需要看到的提示或状态。

7. 用决策表处理组合条件

当条件变多时，口头描述容易漏掉组合。

假设审批规则同时考虑金额和紧急程度：

总金额	是否紧急	直属主管	行政负责人	通知行政
≤ 5000	否	需要	不需要	审批通过后
≤ 5000	是	需要	不需要	提交时立即通知
> 5000	否	需要	需要	全部通过后
> 5000	是	需要	需要	提交时立即通知

逐行检查，可以发现是否有遗漏或互相冲突。

8. 特别检查边界值

“超过 5000”需要至少测试：

• 4999.99；
• 5000；
• 5000.01。

日期规则也有边界：

• 截止当天是否允许；
• 周末和节假日是否计算；
• 跨月时计入哪个期间。

数量规则要检查：

• 空；
• 零；
• 负数；
• 小数；
• 很大的值。

边界不是测试人员最后才考虑的问题，它应在规则设计时被明确。

9. 业务不变量：任何时候都不能被破坏的事实

不变量是比普通规则更重要的业务底线，例如：

• 申请总额必须等于所有明细行金额之和；
• 已完成记录不能再改变申请内容；
• 任何审批任务必须有明确处理人；
• 未经授权的人不能查看其他部门的敏感申请；
• 作废记录不能重新进入采购。

把不变量单独列出，后续每次改版都要重新验证。

10. 处理异常和人工决定

并非所有情况都适合自动判断。可以明确保留人工处理：

异常	处理方式	负责人	需要记录什么
找不到直属主管	不自动提交，提示联系管理员	应用管理员	申请人、时间、原因
紧急采购需事后补批	第一版暂不支持	业务负责人	作为后续需求
批准后发现缺货	行政更新采购结果并说明	行政采购员	缺货原因
申请内容重大变化	作废原申请，重新发起	申请人	原申请关联说明

关键是应用不要静默地把异常当成正常成功。

11. 规则来源和变更责任

每条重要规则应记录：

• 规则编号；
• 业务来源；
• 确认人；
• 生效日期；
• 适用范围；
• 最后修改原因。

这样当有人提出“把 5000 改成 3000”时，应用开发者知道谁有权决定，以及还需要检查哪些流程、视图和测试。

12. 常见错误

• 状态只是页面操作的记录，没有业务含义；
• 只画正常箭头，不说明退回、撤回和作废；
• 同一个词同时用作动作和状态；
• 规则没有边界值；
• 只写满足条件时做什么，不写不满足时怎样处理；
• 计算结果允许随意手工覆盖，却没有说明优先级；
• 规则来自个人习惯，没有业务负责人确认。

13. 本章完成标准

• [ ] 业务对象从产生到结束的状态完整；
• [ ] 每个状态的责任人、可执行动作和可修改范围清楚；
• [ ] 计算、校验、决策和权限规则已分类；
• [ ] 关键规则使用明确的条件—行为—结果表达；
• [ ] 组合条件已经使用决策表检查；
• [ ] 边界值和主要异常已经明确；
• [ ] 业务不变量已单独列出。

下一步

状态和规则说明了“记录怎样变化”，下一章进一步说明“工作怎样在人之间流转”：学习流程、责任与协作边界。