从业务出发：建模会议

先问五个问题，再建模

最常见的错误，是拿到数据库就开始建对象类型：一张表一个类型，一列一个属性。结果本体（Ontology）照着系统的结构长，而不是照着业务的样子长。更好的办法是先开一次会，只谈业务，不谈表。

会议只问五个问题，按顺序问，每个问题产出一张清单：

1. 做哪些决定？

   谁在什么时候、凭什么做决定，做错了代价是什么。

2. 这些决定碰到哪些东西？

   订单、物料、设备……每个「东西」是一个对象类型，写进名词清单。

3. 什么会改变这些东西？

   确认订单、下达工单、登记缺陷……每个「改变」是一个 Action，写进动词清单。

4. 数据在哪、归谁？

   每个属性来自哪个系统、多新才够用、谁负责，写进来源清单。

5. 没有人的时候该发生什么？

   哪些事由数据变化或时间触发、自己做、做到哪一步，写进自动化清单。

示例工厂的五个答案

拿示例工厂（电动自行车整车装配）走一遍。会议一个小时，产出是这张表：

顺序不能乱。先有决定，才知道要哪些名词；先有名词，才知道动词改的是什么；先知道数据从哪来，才能说自动化需要多新的数据。

从清单到对象：三条规矩

• 建模型，不建镜像。ERP 导出里一行同时有客户名、邮箱、产品编码和数量，它描述的是客户、产品、订单三样东西，不是一个 orderData。
• 一个事实只存一处。「客户有几张未完成订单」不要手工维护成整数，用派生属性沿关系数出来，最多 3 跳。
• 每个属性一个写手。同一个状态若既能被人改、又被两个自动化改，迟早打架。清单里每个可改的属性，都写明谁有权改。

再加两个检查：每个对象类型至少被一个决定用到，没有决定用的先别建；名字用业务语言，像 lastInspectionAt，不要用系统缩写。哪些该建成对象、哪些只是属性，见建模方法那一课。

会上还要提防三个常见的坑。听到有人说「先把所有字段都建上，以后再说」，就是第一个坑在敲门：

• 镜像源系统：一列一个属性，什么都不筛。
• 一个对象装下一切：又宽又稀，大半属性是空的，该拆成关系或接口。
• Action 泛滥：每个小变化一个 Action，最后没人记得哪个是哪个。

一页设计与验收问题

四张清单收进一页，就是这次会议的产物。下面是可以直接填的模板：

一页设计 · 〈业务〉 · 〈日期〉 · 〈负责人〉

1. 决定   决定〈…〉  谁〈岗位〉  现在凭〈…〉  做错的代价〈…〉
2. 名词   〈objectType〉  主键〈…〉  3–7 个属性〈…〉  关系（两端的名字与基数）〈…〉
3. 动词   〈action-name〉  参数〈…〉  改〈哪个对象的哪些属性〉  提交条件〈…〉  谁能执行〈…〉
4. 来源   〈系统〉 → 〈对象.属性〉  只读  多新才够〈change 数据变化 / schedule 时刻〉  负责人〈…〉
5. 自动化 〈名字〉  条件〈…〉  效果〈…〉  自主程度〈通知 / 建议 / 批准 / 自动〉  人工关口〈…〉  每天约触发〈…〉次
6. 验收问题（5 个，人和智能体各自只用本体回答）
   〈…〉

写完不要马上建。先出五个验收问题：从各部门反复被问的问题里挑，最好没人事先准备过，比如「哪家供应商的延误让最多工单有风险？」让一个不熟悉模型的人、再让一个智能体，各自只用本体去答。答不出来，说明对象或关系缺了，先补设计。