FDE：将现场证据转化为可运行的业务模型

本文阐述 FDE 如何从现场证据构建业务源模型，定义角色、五步收敛流程、对工程制品的可追溯性以及基线发布标准，确保业务语义得到确认、冲突得以保留，并且模型约束实现而不取代源系统。

业务源模型不是又一份需求文档

文章以一个具体场景开篇：业务专家表示，在延迟审批之后，新日期决定了订单是否逾期。本体工程师、开发人员和 Agent 工程师各自提出不同的问题——审批是对象、事件还是流程；新日期保存在哪个系统和哪个字段；模型是能直接采用该日期还是必须调用工具。这些问题处于不同层面，如果没有一个共享的、已确认的业务模型，讨论就会坍缩为类、属性、接口和提示词。其结果可能是一个没人能用业务语言解释清楚的、正在运行的系统。

上一篇文章（FDE 02）将现场陈述归类为愿望、事实、约束、风险、未知项和非事项，形成现场证据包。下一步不是把这些材料交给各自的技术团队进行临时解读，而是形成一个业务源模型——业务专家可以确认、工程团队可以共同参照、下游制品可以持续追溯。

FDE 的建模职责不是替专家定义业务，也不是替本体工程师选择标准，而是推动现场证据形成一份有归属人、有版本、有确认边界、并可追溯到工程实现与测试的业务模型基线。

“业务源模型”这一术语是作者自定义的概念（并非行业标准）。它指在明确的任务边界内，对业务对象、关系、事件、流程、状态、规则、证据、角色和行为的结构化表达，其中每一项都记录其来源、归属人、确认状态、版本和未决问题。“可运行”并不意味着模型本身执行事务，而是指模型可以被可控地转化为工程制品，约束实现与测试，并持续接收运行时反馈。

业务源模型不是客户的事务或数据权威。它不能取代 ERP、合同、审批、IAM 或其他源系统，将其发布为基线也不授予修改业务状态的权限。它提供的是一个已确认的语义基线；哪个系统持有权威数据、哪个接口执行事务、如何集成与回滚，将在后续架构阶段决定。

该模型也不是：一份改名的会议纪要/术语表/数据库模式；一个直接的 RDF/OWL/UML/BPMN 模型；一个由 FDE 填充未确认规则或冻结所有变更的静态蓝图。

其有效性不是以图的完整性来评判，而是以业务专家是否确认其含义、工程团队能否构建一致的实现、测试失败能否追溯到具体的模型元素和现场证据来评判。

FDE 不定义业务，而是亲自构建工程连接

指派一个“业务兼技术”的人来绘制模型看似高效，却将提供事实、解释规则、形式化、决定实现和承担风险等职责集中于一身。当争议出现时，团队无法判断错误出在业务理解、形式化还是实现上。

本文提出如下职责划分：

业务专家——确认真实案例、术语含义、规则依据、例外情况、业务结果和人工判断。不负责选择 RDF、OWL、数据库或 Agent 实现。

业务模型基线负责人——负责模型范围、跨角色共识、业务能力与领域边界、基线发布和变更验收。不能是一个回避语义冲突和跨部门争议的挂名角色。

FDE——将证据映射为模型候选，组织走查，保留冲突和未知项，建立从模型到工程制品的可追溯性。不能代表授权方确认业务事实、批准权限或接受业务风险。

本体工程师——负责语义形式化、模型约束、转换规则、标识与版本策略。不能因为技术表达完整就假定业务含义已确认。

开发、数据和测试团队——实现数据映射、规则、动作和测试验证，并反馈运行时偏差。不能利用现有字段、接口能力或测试便利反向定义业务语义。

“业务模型基线负责人”可以是业务架构师、领域负责人、业务分析师或其他授权人员。FDE 和供应商解决方案架构师并不默认成为负责人。文章 01 中的业务分析师可能是同一个人，但前者专注于需求和流程分析，而后者负责模型范围、跨领域一致性和基线确认。

在小团队中，一个人可以身兼数职，但职责不能消失。业务事实确认、权限批准、风险接受和技术验证不能因为“大家都参加了评审”就视为完成。

FDE 不仅仅是共创工作坊的协调者。他必须亲自将证据映射到模型候选方案、维护基线和可追溯性矩阵、检查下游实现偏差，并推动相关授权方完成业务确认。

从现场证据到模型基线的五个动作

将现场证据收敛为业务模型，并不是从自然语言到图表的一次性翻译，而是一个受控的收敛过程。

将每个模型候选方案绑定到现场证据。对象、状态和规则必须可追溯到具体的合同版本、审批记录、系统日志、政策条款、正常或异常案例。专家经验判断必须记录判断者、适用条件和例外情况——而不能被升级为普适规则。

先用业务语言表达，再选择技术表示形式。团队应先厘清“什么对象在什么条件下因哪个流程发生怎样的变化”，然后再决定它进入本体、规则引擎、工作流、代码还是动作契约。技术团队可以提出表示形式建议，但不能让某个标准的易表达性反过来裁剪业务事实。

冲突不得被静默合并。如果两个部门对“交付日期”的理解不同，就不能为了统一字段而将其合并。如果合同、订单和延期审批给出的日期不一致，开发人员不能挑选最稳定的接口。冲突应作为未决事项保留在模型中，记录影响、责任人、验证方式和截止期限。必要时可为当前基线缩小范围。

发布的是模型基线，而非最终真理。基线必须包含模型版本、适用任务和范围、确认人、未决事项、变更日志和生效时间。“已确认”意味着“在当前证据、范围和时间下可作为共享工程版本使用”，而不是“永远正确”。

同时建立下游可追溯性。每个关键模型元素都必须标明受影响的数据映射、规则、流程、动作、Agent 工具和测试。下游偏差必须生成变更或偏差记录；禁止静默的语义修改。

因此，一份可交付的业务模型基线不仅包括模型图，还包括模型主体、术语与证据索引、确认与未决事项、下游可追溯性矩阵，以及版本与变更记录。

通过异常订单场景收敛业务语义

继续这个综合案例：现场证据显示合同版本、ERP 订单和延期审批的日期可能冲突；外部客户承诺的变更需要指定业务负责人的审批；第一阶段不会自动修改 ERP 排程或客户承诺。

如果团队直接跳到技术实现，他们很可能会创建一个单一的

delivery_date

字段加优先级规则（例如优先取 ERP 或最新审批）。业务模型则将不同概念分离：

订单 —— 被履约和跟踪的业务对象。

合同版本与延期审批 —— 用于确认履约承诺的证据，并不自动等同于当前有效承诺。

履约承诺 —— 记录适用的订单、有效期、依据及确认状态。

履约风险任务 —— 记录一次风险判断及其证据、规则版本和人工确认结果。

确认当前履约承诺 —— 解决冲突的业务流程；不能被字段优先级规则取代。

在当前基线中，“履约承诺”可以有“待确认”“有效”“已取代”三种状态。当多个依据发生冲突时，模型将承诺保持为“待确认”，并触发由有权限的业务方进行确认。在确认之前，系统可以提取材料、比对日期并识别冲突，但不得给出最终的履约结论。

这一步并不决定数据存储或事务权限；它冻结的是所有工程团队都必须遵守的业务语义：多个日期不是同一字段的副本，审批记录并不天然是有效承诺，未知状态不能被模型或代码悄悄填补。

下面的简化追溯矩阵说明了职责接口（数字和内容仅用于说明方法，并非真实的客户模型）：

模型元素：具有标识、有效期、依据的履约承诺。字段证据：F‑01 日期冲突、合同与审批材料。下游产物：本体概念、数据映射、数据约束。最低验证：同一订单的多版本与冲突样本不得被悄悄合并。

模型元素：履约承诺状态（待确认、有效、已取代）。字段证据：U‑01 未知项与业务确认结果。下游产物：状态模型、流程或对象运行时约束。最低验证：非法状态转换和缺失确认记录不能进入“有效”状态。

模型元素：多个依据冲突 → 不得自动选定最终承诺。字段证据：U‑01、C‑01。下游产物：规则模型、决策服务、异常处理。最低验证：冲突样本只能进入人工确认或受控阻塞。

模型元素：生成处理建议。字段证据：W‑01、C‑01。下游产物：动作契约、Agent 工具描述、人工确认点。最低验证：工具调用保留证据，且不能越权更改客户承诺。

模型元素：阶段 1 不修改调度和客户承诺。现场证据：N‑01。下游产物：工具白名单、权限策略、接口范围、禁行测试。最低验证：Agent 缺少相关写工具或写权限。

模型元素：结论必须返回来源和规则版本。现场证据：F‑01、R‑01。下游产物：证据结构、审计日志、评测样本。最低验证：每条结论均可追溯至材料位置和规则版本。

这张表不是对所有技术产物的一次性设计；它确立的是责任接口：业务专家确认语义，本体工程师和开发人员进行形式化与实现，测试团队验证一致性，FDE 维护证据、模型、产物与测试之间的闭环。

上图给出了从业务基础到工程产物的概览。在业务模型内部，六个概念的关系如下：

模型必须进入工程，而不是停留在图纸上

业务源模型可以按需转化为多种技术产物：概念和关系转化为 RDF 或 OWL；通过 SHACL 对 RDF 数据施加约束；流程映射到 BPMN 或现有工作流引擎；接口和数据结构由 OpenAPI 和 JSON Schema 契约约束。项目不必采用所有标准，但必须有明确的转化关系和一致性验证。

模型与工程产物之间必须保留至少四类可追溯性：

来源可追溯性：每个模型元素源自哪些现场证据和业务确认。

转化可追溯性：每个模型元素生成或约束了哪些本体、数据、规则、流程和契约。

验证可追溯性：每个元素由哪些正常、异常、冲突和越权样本验证。

运行时可追溯性：生产偏差、人工接管和规则例外影响哪个模型版本。

可追溯性不能只是文档链接。模型元素、工程产物和测试必须有稳定的标识符和版本；否则无法证明模型更新已进入运行中的系统。

业务模型基线何时可以发布？

模型首次发布时不必覆盖整个领域，但必须完整支持当前任务边界。发布前至少要确认以下事项：

模型范围、基线负责人、确认人和适用时间是明确的。

关键对象、关系、状态、规则和行为都有正常、异常或冲突案例支撑。

同名异义、异名同义和跨系统冲突没有被悄悄合并。

业务规则、专家判断、AI 判断和人工确认之间的边界是可区分的。

未知项、非条目和权限边界保持可见，并附有处理路径。

关键模型元素可追溯到现场证据、下游产物和验证样本。

版本、生效条件、变更入口点和重新验证范围均被记录。

如果一个模型只有对象和关系，而没有状态、证据、动作和责任边界，它就无法支撑一个可运行的系统。如果它有完整的图示，却缺少责任人、版本和测试可追溯性，它仍然只是一份建模文档。

AI 可以帮助提取候选术语、比较材料版本、生成模型草稿、发现冲突、补全追溯链接和生成测试样本。但 AI 无法决定哪种业务解释是有效的，无法代替授权方合并冲突概念，也无法批准权限、接受风险或发布业务模型基线。

FDE 可以使用 AI 来加速建模，但仍需负责确保证据被保留、冲突被暴露、确认责任清晰，以及模型真正进入工程。

业务模型的终点：架构决策的输入

业务源模型将现场知识转化为工程团队可以共同参照的语义基线，但它并不决定哪个系统拥有履约承诺数据、跨系统信息如何同步，或者哪些能力进入产品平台、配置扩展或人工处理。

这些不是业务模型应该单方面决定的问题；它们是下一步——必须基于现场证据和模型基线做出的系统边界与架构权衡。

这将是本系列第 04 篇文章的主题。

参考文献

本体建模连接业务与技术：标准不是业务入口，而是编译目标 (https://mp.weixin.qq.com/s?__biz=MzcwNDM2MTg3NA==&mid=2247484439&idx=1&sn=a325781c1b801710755976cf58bb09f3&scene=21#wechat_redirect)

W3C：Shapes Constraint Language (SHACL)

OMG：业务流程模型与标记法 2.0.2

OpenAPI 规范 3.1.1

JSON Schema 草案 2020-12

已登录的读者可以通过 BestHub 的受保护跳转打开原始来源。

登录以查看来源

本文由源材料提炼和总结而成，随后为学习和参考目的重新发布。如果您认为它侵犯了您的权利，请联系我们，我们将及时审核。