统一业务语言，识别业务对象
本章目标：让所有参与者对关键业务词使用同一种含义，并识别应用究竟需要管理哪些“东西”。
1. 为什么词语不统一会让应用失控
同一个团队里，“完成”可能有三种含义：
- 申请已经审批通过；
- 行政已经下单采购；
- 物品已经交给申请人。
如果不先说清楚，可能出现：
- 流程在“审批通过”后结束，但申请人以为物品已经到货；
- 月报把“已批准”当成“已采购”统计；
- 行政和财务对同一个状态理解不同；
- 测试人员无法判断结果对不对。
建立业务词汇表不是形式工作，而是在防止所有后续设计基于不同理解。
2. 先认识五类业务词
| 类型 | 解释 | 采购案例 |
|---|---|---|
| 角色 | 参与业务的人或职责 | 申请人、直属主管、行政采购员 |
| 对象 | 业务中需要持续管理的事物 | 采购申请、物品、采购明细 |
| 属性 | 描述对象的信息 | 申请日期、用途、数量、单价 |
| 动作 | 人或应用对对象做的事情 | 提交、审批、退回、完成采购 |
| 状态 | 对象当前处于哪个阶段 | 草稿、审批中、待采购、已完成 |
把这些类别混在一起，会直接影响应用结构。例如“审批通过”是一次动作产生的结果，也可能对应一个状态，但它不是一个新的业务对象。
3. 什么是业务对象
业务对象是业务人员会反复创建、查看、处理、追踪或统计的一类事物。
可以用四个问题判断：
- 它是否有自己的名称或编号？
- 它是否会经历一段时间和若干状态？
- 人们是否需要单独查询或统计它？
- 它是否会被多条其他业务记录引用？
满足越多，越可能是一个独立业务对象。
采购案例
采购申请显然是业务对象：
- 每项申请有自己的编号；
- 会经历草稿、审批、采购、完成等状态；
- 用户需要查询进度；
- 管理者需要统计数量和金额。
申请用途不是独立对象：
- 它只是在描述一项采购申请；
- 不需要单独经历状态；
- 一般不单独管理。
所以“用途”更适合作为采购申请的一个属性。
4. 对象、记录和字段的区别
以“采购申请”为例：
- 业务对象：采购申请这一类事物；
- 一条记录：张三在 7 月 20 日提交的那一笔采购申请；
- 字段：申请编号、申请日期、用途、总金额等描述信息。
对小白来说，最常见的错误是把字段误当成对象：
- “供应商名称”只是一个文本，还是需要独立维护的供应商？
- “项目”只是手填名称，还是有负责人、状态和预算的项目对象？
- “物品”只是每次临时输入，还是需要统一编码和价格的物品目录？
判断依据不是名字，而是业务是否需要对它独立管理。
5. 基础资料与业务单据
业务对象通常可以粗分为两类。
5.1 基础资料
相对稳定、会被许多业务反复引用：
- 物品目录；
- 客户；
- 供应商；
- 项目；
- 费用类别。
基础资料的重点是统一、准确、避免重复。
5.2 业务单据
记录一次具体业务发生：
- 采购申请；
- 费用报销；
- 合同用印申请；
- 客户拜访记录。
业务单据通常有发起人、发生时间、状态和处理过程。
第一版不一定要把所有基础资料独立出来
采购案例第一版如果物品种类少，可以先允许申请人填写物品名称；当出现统一编码、固定价格、库存关联等要求时，再把物品升级为独立管理的基础资料。设计应服务于当前明确需求。
6. 主信息与多行明细
很多业务单据由两部分组成：
主信息：整张单据只有一份
- 申请编号；
- 申请人；
- 申请日期；
- 采购用途；
- 总金额；
- 当前状态。
明细：一张单据可以有多行
- 物品名称；
- 规格；
- 数量；
- 单价；
- 行金额。
判断一个字段应该放主信息还是明细，可以问：
同一张单据中，这项信息会不会出现多次，而且每次都和某一行内容一起变化？
“申请日期”整张单据只有一个，属于主信息；“数量”每种物品各有一个，属于明细。
7. 识别对象之间的关系
常见关系包括：
一对多
一项采购申请包含多行采购明细。
多对一
多项采购申请可能属于同一个费用类别。
相互引用
采购申请可能引用物品目录中的物品，客户拜访记录可能引用客户。
分析关系时要问：
- 谁可以独立存在？
- 删除一方时，另一方应怎样处理？
- 引用的是当前信息，还是要保留当时的事实？
- 一个对象可以关联一个还是多个？
8. 当前信息与历史事实
企业业务经常需要同时处理“现在是谁”和“当时是谁”。
例如申请人后来改名、转部门或离职：
- 当前查看人员资料时，应显示他现在的信息；
- 审计一笔历史申请时，仍应能说明提交当时的人员和部门事实；
- 工作交接可以转移当前责任，但不能把历史申请人改成接手人。
业务开发者需要在需求中明确：
- 这是一个当前责任，允许交接；
- 还是一个历史事实，必须保留。
采购案例中：
- “当前采购负责人”是当前责任，可以交接；
- “申请提交人”是历史事实，不应随交接改变。
9. 建立业务词汇表
词汇表至少包含：
| 术语 | 统一定义 | 不包括什么 | 示例 |
|---|---|---|---|
| 采购申请 | 员工为工作需要提出的办公用品购买请求 | 不等于实际采购订单 | PA-2026-001 |
| 审批通过 | 所有规定审批节点已同意 | 不代表已经采购 | 主管和负责人均同意 |
| 采购完成 | 行政已完成购买并登记结果 | 不代表申请人已领用 | 已填写采购日期 |
| 作废 | 业务不再继续，记录保留但终止处理 | 不等于删除 | 需求取消 |
“不包括什么”很重要，它能主动消除相近词之间的混淆。
10. 建立业务对象卡
每个候选对象都填写一张卡：
| 项目 | 采购申请示例 |
|---|---|
| 对象名称 | 采购申请 |
| 业务目的 | 记录并推动办公用品采购请求 |
| 谁创建 | 有申请权限的员工 |
| 谁负责 | 申请人；批准后转为行政采购员 |
| 何时产生 | 员工确认有采购需要时 |
| 何时结束 | 采购完成或申请作废 |
| 主要状态 | 草稿、审批中、待采购、已完成、已作废 |
| 主要信息 | 用途、明细、金额、审批结果、采购结果 |
| 与其他对象关系 | 包含多行采购明细 |
| 需要怎样查询 | 我的申请、待采购、按月统计 |
11. 检查是否拆得过细或过粗
过粗的信号
- 一张表包含多个彼此独立的业务过程；
- 同一字段在不同状态代表不同含义；
- 大量信息只有某一类记录才使用；
- 权限和流程无法针对其中一部分配置。
过细的信号
- 每一个下拉选项都被设计成独立对象；
- 两个对象永远一起创建、一起结束、从不单独查询；
- 为了填写一张简单申请，用户需要在多个页面来回创建内容；
- 拆分没有解决任何明确业务问题。
12. 常见错误
- 按现有 Excel 的工作表直接决定业务对象；
- 把页面、状态或操作按钮当成对象；
- 因为“以后也许会用”就把所有名词独立管理；
- 忽略主信息与多行明细的区别；
- 只引用当前人员信息，没有考虑历史事实；
- 术语表只有名称，没有清楚定义。
13. 本章完成标准
- [ ] 关键业务词都有统一定义；
- [ ] 已区分角色、对象、属性、动作和状态；
- [ ] 每个独立对象都有明确业务目的；
- [ ] 已识别主信息和多行明细；
- [ ] 对象之间的关系能够用业务语言说明；
- [ ] 已区分当前责任和历史事实；
- [ ] 没有直接照抄现有 Excel 结构。
下一步
确定“管理什么”之后，要说明这些对象会怎样变化。下一章学习生命周期、状态、动作与业务规则。