前面我分享过一套手机行业的TOGAF企业架构规划案例参考。今天继续结合这套企业架构材料，来看下如何基于企业架构来构建本体模型。
一、起因：手机行业的 TOGAF架构参考文档
按 TOGAF 的 9.2 ADM 方法论，我把这套规划拆成了 7 章文档（总纲 + 战略 + 业务 + 数据 + 应用 + 技术 + 实施），总共加起来差不多 70 万字；外加 50 多份 Excel 附件（按章节编号，每章都有业务域清单、能力分解、矩阵追溯、决策记录等），还有 70 多个 HTML 可视化图、120 多张 PNG 配图。文档结构按 TOGAF 各阶段严格对齐，主线很清楚：用 LTC（线索到回款）这条价值流把六个架构域串起来。
这一整套东西做完之后，我自己心里一直有个疑问：TOGAF 文档虽多，但它还是偏"规划视角"——告诉你"要做什么"，不直接告诉你"业务系统里到底有哪些表、字段、动作、约束"。换句话说，它回答的是架构问题，不是数据问题。如果想真正做一套能落地的业务系统，光有 TOGAF 文档还不够，还得往下挖一层，把业务世界的"结构"和"动作"挖出来。
所以，我做了一个尝试：从这一整套 TOGAF 文档里，把那些核心的业务对象、业务行为、业务规则识别出来，再用规范的本体建模方法把它结构化，最后拿真实业务去验证——这个模型到底能不能撑得起 LTC 端到端流程。
这篇文章就是这个尝试的完整记录。
二、抽象：把规划文档里的内容拆成四类东西
第一步是抽象。TOGAF 文档里虽然东西多，但归纳下来其实就是四类：业务对象（名词）、业务行为（动词）、业务规则（约束）、业务场景（端到端流程）。这四类正好对应到本体建模的四个核心元模型。
具体怎么做的呢？我把手机厂的 8 大业务域（供应链、产品研发、生产制造、市场营销、售后服务、人力资源、财务、战略经营）一个一个过了一遍，每个域输出一份 Markdown，三张表：
业务对象表：列出这个域里"业务系统里真实存在的业务实体"，比如物料、销售订单、客户应收、销售合同这种 ERP/CRM/MES 里的核心业务表。配置表、字典表、流程定义表不算。每个对象给一个名字、五分类标签（主数据/事务/行为/规则/指标）、来源系统、还有它涉及的业务行为。 业务行为表：动词，比如"创建采购申请""确认交期""生成报价单"。每个行为都标清楚它归属哪个对象、会产出/修改哪些对象、属于 COMMAND 还是 QUERY、跑在哪个系统里。 业务规则表：条件和约束，比如"金额超过 50 万要总监审批""超过账期自动冻结发货"。每条规则点明作用于哪些对象、违规怎么处置。
8 个域全过完，最后统计：206 个业务对象、182 个业务行为、93 条业务规则（后来二次拆分时微调过几次，数字大致稳定）。
这里举一个对象当例子——销售订单（AGG-MKT-008）。它在 Markdown 里的属性列是这样的：订单号（必填）、客户、关联合同、产品/SKU、数量、单价、交期、发货状态、开票状态、收货状态。这些属性不是凭空写的，而是按 ERP 里"销售订单表"的真实字段对照着列的；五分类上它是事务数据 TD，来源系统是 CRM/ERP。我对每个对象都按这个口径去列，确保将来直接拿这套表去做表结构设计不会跑偏。
不过第一遍抽完之后自己又看了一遍，发现一个明显的问题：很多对象名用了斜杠"物料/BOM""工厂/车间"，其实它们是两个东西，不该塞在一个名字里。这个错误在系统表里就是两个表，混在一起将来没办法做关联和依赖。所以我又回头重做了一遍，把"工厂"和"车间"、"工序"和"工位"、"销售发货单"和"销售出库单"、"运单"和"提单"、"保修登记"和"服务合同"这种容易搞混的，全部拆成两个独立对象。这一轮重做挺费时间的，但拆完之后整个模型的颗粒度就对了，跨域追踪也顺了。
接着是场景。我把 LTC（线索到商机→报价→合同→订单→交付→开票→回款）拆成 7 个独立子场景，每个场景一份 Markdown，表格的每一行是最细粒度的业务行为，标清楚这一步谁干的、读哪些对象、写哪些对象、跑在哪个系统、用到哪条规则。光 LTC 一共就抽出来 7 个场景文件。其他端到端的（IPD、ISC、P2P、P2R、I2R、H2R、S2E）我也顺手做了 7 个，加起来总共 14 个场景文件。
到这里为止，22 份 Markdown 文件躺在我工作目录下，每个域一份、每个场景一份，都是表格化的、便于机器读的。
三、建模：用本体建模规范把 Markdown 转成 YAML
Markdown 是给人看的，机器没法直接用。下一步是建模。
我手上有一份《本体建模规范》（v1.0，八个模型那一套，里面把对象、行为、规则、场景的 YAML Schema 都规定好了）。我写了一个 Python 脚本，直接把前面那 22 份 Markdown 表格解析进去，按照规范输出 4 个 YAML 文件：
objects.yaml：206 个聚合根（aggregate），每个带 id、name、五分类、来源系统、属性列表、关联的行为和规则；behaviors.yaml：182 个行为，每个带 ownerEntity、behaviorType、outputObjects、appliedRules；rules.yaml：83 条规则，每条带 ruleType、appliesToObjects、condition、violationHandling；scenarios.yaml：14 个用例 + 8 个业务过程，每个用例的 primaryFlow 里写清楚每一步读什么、写什么、触发哪个行为、谁负责、用什么系统。
这一步的产出我挨个校验过：4 个 YAML 都能用 PyYAML 正常加载，对象的跨域引用 100% 解析得上，规则和行为也都能挂到正确的对象上。
不过脚本也不是一遍就写对的，中间踩了几个坑值得记一下。第一个坑是属性误拆——Markdown 里属性列是用逗号分隔的中文短语（这是规范要求的），但有些属性本身就含斜杠，比如"产品 SN/IMEI"、"渠道(热线/在线/门店)"，第一版脚本按逗号+斜杠一起切，结果把括号里的内容也切碎了。后来改成只按逗号切就解决了。第三个坑是ID 归一——有些对象的写法带括号变体，比如"采购订单(已发布)"和"采购订单"其实是同一对象的两处引用，脚本要做去括号归一才能正确连上。第二个坑是场景里行为引用的命中率——14 个场景每一步都写了要触发哪个行为，但场景是按动作描述写的，行为表里的命名有时略不同（比如"创建采购申请" vs "采购申请创建"），只能做最佳匹配，最后大约 154 个步骤里命中了 49 个，其余保留原文，等后续做语义对齐再补。这些坑在第一次跑模型的时候都暴露出来了，修完之后模型才真正能跑得动。
做完这一步，我心里其实在等最后一道验证：这堆 YAML 模型，到底能不能真的把 LTC 撑起来？ 毕竟，前面都是"画"，最后这一步才是"验"。
四、验证：用真实业务场景跑一遍 LTC
验证的方式很简单：按 LTC 的流程顺序，一个对象一个对象地走。看每个阶段需要的对象在不在、行为在不在、规则能不能兜得住。
第一段，线索到商机到报价。 这段在手机厂商里其实很碎——线索从市场活动、官网、渠道、门店各种口子进来，要先评分、再培育、再转化成商机，最后才能给报价。我从 YAML 里找出这一段需要的东西：线索（AGG-MKT-002）、商机（AGG-MKT-003）、客户画像（AGG-MKT-004）、客户标签（AGG-MKT-005）、报价单（AGG-MKT-006）、产品价格定价表（AGG-MKT-021）；对应的行为有线索录入、评分、培育、转化、商机创建、推进跟进、生成报价单（BEH-MKT-002 到 012）；规则有价格有效期约束、渠道信用控制。重点在哪儿呢？报价单不是一个数字，而是被对象关系约束出来的产物——它的价格来自定价表，折扣受规则控制，状态有生命周期。这一段模型能撑住。
第二段，报价到合同。 报价被客户接受了，接下来签合同。这里我用到了 RULE-MKT-005"合同-订单一致性"和 RULE-MKT-009"渠道信用控制"。前者保证后续订单和合同对得上，后者保证超信用的合同签不下来。销售合同（AGG-MKT-007）这个对象本身有产品明细、金额、条款、签约日、生效日这些属性，下游所有系统读到这份合同时，拿到的都是同一份被校验过的语义。这一点很重要：模型在语义层把"合同"这件事说死了，不会出现合同系统和 ERP 对合同理解不一致的情况。
第三段，合同到订单到交付。 这是跨域的一段。生成销售订单（AGG-MKT-008）的 BEH-MKT-014 是以销售合同为输入依据的；接着供应链那边，创建销售发货单（BEH-SUP-026）、销售出库过账（BEH-SUP-027）。这里有个小细节值得说一下：销售发货单和销售出库单是两个独立对象，不是合并的"发货/出库"。前者是履约指令、后者是物权转移凭证，语义不同、系统归属也不同（WMS/ERP）。正因为模型在对象层面分得这么细，财务那边才能据此确认"货权已转移"再去开票。这种颗粒度在传统流程图里是看不到的。
第四段，交付到开票到回款。 收尾的是钱。销售开票（BEH-FIN-003）→ 收款（BEH-FIN-004）→ 收款核销（BEH-FIN-005）这一串行为，把销售发票（AGG-FIN-008）、客户应收（AGG-FIN-007）、收款单（AGG-FIN-011）三个对象串了起来。规则那边用 RULE-FIN-004 账期信用控制兜底。这里还顺手发现一个有意思的事：RULE-FIN-001"三单匹配强制"虽然当前用在采购发票上，但它"订单、收货、发票一致才能入账"的逻辑，跟销售侧的合同-发货-发票一致性其实是同源的。一套规则，在应付和应收两端都能用得上——这是建模型的额外收获。
四段走完，我把整条链路记下来：线索 → 商机 → 报价单 → 销售合同 → 销售订单 → 销售发货单 → 销售出库单 → 销售发票 → 客户应收 → 收款单，十个对象一气呵成，每一步都是"对象被行为读写、被规则校验"的确定事件。这条链路在 TOGAF 文档里是有的，但都是规划层面的；现在我用本体模型把它落实到了具体的对象和行为上，可以直接被系统读、被规则卡、被跨域穿透。
五、为什么这套模型能"撑"得住
回头看，模型能撑住 LTC，主要靠四件事。
第一，可追溯。 每个行为都标了 ownerEntity 和 outputObjects，每条规则都标了 appliesToObjects，三个东西互指。想知道一个对象被哪些行为动过、被哪些规则约束过，顺着引用查就行；反过来想知道一个场景的每一步读写什么对象，从场景的 primaryFlow 里也能直接看到。这条链子是双向通的。
第二，口径一致。 同一个对象在不同系统里只有一个权威定义。客户主数据就是客户主数据，CRM 和 MDM 共用同一份；销售订单从 CRM 流到 ERP，语义不变。流程图上的"断点"，在模型层因为共享对象就被抹平了。
第三，规则在前。 信用、价格、合同一致性、三单匹配这些约束，不再藏在某个系统的代码里，而是作为独立的规则对象挂在网络上，作用于具体的对象。行为还没执行，规则就已经在线等着了，不靠人盯。
第四，跨域能通。 LTC 之所以能跑完，靠的是营销、供应链、生产、财务这四个域的对象在模型层互相对得上。TOGAF 文档里说要"打通"，但没告诉你怎么打；现在的模型里，对象就是那个"打通点"。
六、再往后的事：模型不只是规划用的
这件事做完之后，我发现这套模型还有几个意外的好处。
一是知识图谱天然可用。 我拿这 4 个 YAML 直接生成了一个 ECharts 知识图谱，485 个节点、1087 条关系——对象画得最大、用青色，行为是琥珀色，规则是紫色，场景是绿色。LTC 的主干在图上一眼就能看清。这玩意儿给业务部门开评审会特别好用。
二是大模型也能用得上。 行为声明了 ownerEntity 和 outputObjects、规则声明了 appliesToObjects，等于给 Agent 提供了一份"我能做什么、改什么、受什么约束"的可执行接口，不用再去猜。这对后面要做 AI 助手或自动化代理很关键。
三是变更能追。 改一个字段、调一条规则，立刻就能在网络里回溯影响范围——哪些行为、哪些场景、哪些下游对象会受影响。手机行业的产品迭代和合规变更很频繁，这一点特别管用。比如某次"信用规则放宽"的内部讨论，决策会上马上就能在图谱里圈出：这条规则一旦改了，会直接松绑多少个客户、多少个订单环节、影响多少个下游对象的处理逻辑——以前这种影响分析得靠开会+猜，现在模型里直接出。
四是新员工培训用得上。 让新人快速看懂一家公司的业务最快的方法就是给他看这张图——对象节点的大小代表它在整个业务里被用到的频次，颜色区分它的角色，新人对着图问"这个是干嘛的、谁在动它、什么时候会被卡住"，基本能自己摸出 80% 的业务轮廓。这比读 PPT 培训材料快多了。
七、写在最后
回头看，这件事其实就三步：先是做 TOGAF 规划，把"做什么"想清楚；再从规划里抽象出对象、行为、规则、场景，把"怎么做"的结构挖出来；最后用规范的本体建模方法把它形式化，再用真实的 LTC 流程去验证。这三步做完之后我最大的感受是：规划文档再厚，没有本体模型托底，它还是浮的——落到系统里的时候照样会断链、会扯皮、会口径不一对不齐。本体模型其实不是规划之外的东西，它是规划真正"落地"的那一层。
如果你手上也有 TOGAF 文档，建议走一遍这个流程——抽象、建模、验证三步，得到的不是又一个文档，而是一张可以被系统读、被规则卡、被 Agent 用的活网。
如果让我再来一遍，有几个建议想提前说：第一，抽象阶段就把"斜杠合并"的坑过一遍，不要等模型跑出来再回头拆，越晚拆代价越大；第二，对象属性一定要直接对照真实系统字段，别拍脑袋拍出来的属性将来落到代码里全是空架子；第三，规则一定要挂到具体对象上，而不是写在流程图旁边，否则模型再漂亮也约束不到执行；第四，验证这一步别省，光看 YAML 加载没报错不代表它能跑业务，必须拿真实端到端流程一个对象一个对象地走一遍，把断点暴露出来。这四件事当时我没全做对，第二件和第四件是事后才补上的，记下来给自己也给别人提个醒。
