
大家好,我是人月聊IT,今天继续聊本体论建模。
如果大家看过我前面和本体论相关的文章,可以看到。最早我基于合同管理的需求场景,基于对象行为规则为建模核心,构建了一个由Markdown格式文件组成的合同本体元模型。
在第二次迭代的时候,通过和AI大模型的交互,整个本体模型进一步进行了扩充了,增加了主体模型,异常补偿模型等关键内容。而且AI在深刻理解我的意图后,帮我输出了一个完整的本体论建模规范,并给出了可以用Yaml文件来更加精确化的定义本体模型。

这个本体模型核心仍然是对象+行为+规则。但是和传统的OWL知识图谱语义建模有区别,其中关键的区别点在于。
其一是结合了EDA事件驱动架构的思想,通过消息事件来实现对象行为解耦。其二是将规则模型独立出来,规则对象本身是可以复用的,可以被多个行为所引用。其三是增加了场景模型,通过场景模型来实现底层行为规则的动态组装。通过这些改进让整个本体建模可以更好的实现后续的数据反向驱动业务的能力,包括实现后续顶层流程场景变化后,可以通过AI大模型动态组装的能力。

当然我拿到建模规范以后,因为我原来本来就写有一个详细的合同管理的需求。我刚好就用合同管理这个需求,对我整个建模规范做了进一步的验证,所以说 AI 它又会基于合同管理的需求,给出了一个合同管理系统本建模过程的总结。包括具体的业务背景,建模的边界。核心的业务价值链,包括整个的行为的识别事件链的设计对象的建模行为的建模,规则的建模,所有的内容它都会有一个完整的总结。

合同的本体建模规范建完了以后,它是针于每一个模型,它都会输出一个 yaml 的文件。大家可以看到这个地方就会有对象的模型文件行为的模型文件规则的模型文件和场景的模型文件。
通过这么一些模型源文件共同就构成了合同管理的本体。在这一步做完了以后,我接着我就在想我们能不能简单的通过VibeCoding做一个简单的本体模型的编辑器。
所以说我刚好就是借助 AI 的辅助编程工具,我把我的这个想法需求给了 AI 以后,让 AI 通过编程来帮我实现这么一个简单的小的应用。整个应用也很简单,前端就是Typescript 加 React,后端就用 Python 语言加 Flask。基于这么一个编程组合,然后整个大模型就去输出了完整的代码,然后整个系统基本上就可以跑起来。
这个系统的操作演示视频大家可以参考我同名视频号下面3.16日发布的视频。在讲这个小应用的时候还是想讲一点。实际我做个使用了Codex5.4,GLM5.0,Geminipro3和Claude4.5。实际最终效果最好,一次输出成功的只有Claude大模型。这个也再次验证了我原来讲过的一句话,就是在AI编程领域来说只有Claude大模型和其它。
我们先来看下整个系统运行起来后整体界面风格如下:

整个系统打开以后,它就是这么一个本体模型编辑器,然后我们需要打开一个工作区,这个工作区就是存储我刚才的压模文件的这么一个目录,然后点击打开以后我们就可以看得到左片就形成了一个完整的模型树。
模型树里面首先就有对象模型。比如我们的产品客户部门人员合同都是我们的核心的对象,当把合同展开的时候,每一个对象模型下面又有两个子节点。一个属性,一个行为属性就是。
可以看到合同这个对象就有合同编号,名称,所产品,责任人,签订时间这些关键属性信息。具体的行为可以理解成传统的面向对象编程里面的方法,比如它会有录入合同的行为。关闭合同的行为。

只是我在这个地方做了一些增加,因为每个行为它还可能调用到相关的一些规则。在行为下面我们可以看得到它究竟引用了哪一些参考完整性规则。比如说合同的录入,它其实引用了两个规则,一个是合同金额合规性校验规则,一个是税率合规性校验规则。
每个规则它有详细的名称定义,包括一些规简单的伪代码或者叫规则表达式,包括不符合规则的一些提示的语句,这样的就形成了完整的对象模型。我们再来看行为模型一样的,就是把对象里面的行为抽出来行为下面挂有具体的规则的引用。

然后我们再来看规则模型。规则模型是一个独立的模型,我们会把因为为什么要把规则模型抽出来?同样一个规则有可能是在不同的对象,不同的行为多次引用它是一个可复用的东西。
我们把规则抽出来以后,我们再展开,我们就可以看得到这个规则当前究竟被哪几个对象引用?所以说我当前你们看到的这个模型树看起来好像是一个一层一层展开的树状结构。由于节点和节点之间有这么一种双向引用关系,它其实就构建了一个类似于知识图谱的网络结构。

在规则模型完了以后,我们就还有事件模型是在新的本体建模里面专门增加的内容。就是希望通过EDA事件驱动架构,通过事件链的思路实现对核心的端到端流程的支撑。包括我一直强调的传统了流程驱动模式构建的是长周期事务,而EDA事件驱动架构可以通过异步消息机制更好的实现解耦。
从上面截图可以看到,任何一个事件我们可以看得到,它一定有两类。一类就是这个事件由哪个对象的行为触发的。第二个就是事件发出了以后究竟有哪一些新的对象需要消费和订阅事件。
类似于合同已录入,我们就可以看得到它的触发对象是合同,它的订阅对象是付款条款这个对象。这样的话通过事件就很好的将各个对象本体之间完整的连接起来了,而且通过事件实现了关键的一些消息的回写。

在事件模型最后一个场景模型。场景模型其实就是我们完整的一个业务功能或者流程,场景模型的本质是多个行为事件规则一的之间的一个组合或者是组装。跟我原来讲SOA面向服务架构的思路完全是一样的。我们如果打开任何一个场景,我们就可以看得到它核心的主流程。比如说在这个地方录入合同,我们就可以看得到,它其实是分了四个步骤。

第一个录入合同,第二个等待事件,第三个批量创建付款条款。第四个等待事件。这样的通过行为规则相关的组合,我们就完成了一个完整的业务功能,包括业务功能更上层之间的流程。
所以我们点任何一个对象的时候,在右边我们就可以看得到对象详细的一些基本信息详细信息,比如说规则一,我们可以看得到规则的详细信息,规则的定义,规则的表达式包括违约提醒等。
我们可以在这边去做相关的修改完了以后,我们可以去做相关的保存操作。包括在保存前,你也可以去做参考完整性校验,这样的话就完成了一个完整的本体模型的一个编辑完的内容,它同时会重新存储为我们独立的四到五个 yaml 文件。

在我把整个本体模型建完了以后,我们又增加一个可视化知识图谱的功能,就是我们点这个知识图谱的时候,它会动态的去读读取这个模型的元数据,然后将这个模型展转化为一个动态的知识图谱的展现在这个知识图谱上面。我们可以看到对象支撑域的对象行为规则,事件,场景都有完整的演示。
然后我们这个地方还可以去过滤,我们可以只看对象,只看行为。只看规则,只看事件,只看场景,这样的话,其实就是一个本体完整的知识图谱。它构成了一个完整的知识网络相互之间相互依赖,相互关联,形成了一个完整的,闭环的相互影响,制约的这么一种逻辑结构。
当然在我前面我还做了一个演示,就是我们可以基于场景的实现步骤来通过知识图谱动态的模拟整个实现过程我们可以点击下一步不断展现整个完整模拟过程。
比如说对于合同录入流程,我们可以来完整的动态模拟这个过程。

首先第一步就是会有一个合同录入流程的这么一个节点。大家可以看到,在朝下面走的时候,他首先要去做客户创建客户创建的时候,他需要调用业务规则处理,处理完以后形成客户数据存到客户的对象或者数据库表里面。

第二步,他需要去创建产品。产品创建的时候,也需要调用相关的规则,最后形成产品数据落库到产品的数据对象表里面。

第三步,它需要进行合同创建。合同创建的时候,它又会去调用相关的类似于合同的完整性校验参考规则校验的规则规则调用完了以后,最终它会形成相关的合同数据和合同的付款条款数据。这是一个主明细的数据对象表,然后存到这个表里面去。

最终形成一个完整的,基于合同录入场景的这么一个本体论的图谱。所以大家从这个图可以看到我实际的场景对象行为规则,它是高度融合的,它是形成一个完完整整的一个知识网络的图谱。
以上就是今天我想简单给大家演示的一个本体模型的一个编辑器,包括本体模型你做完以后的一个可视化知识图谱的展现。希望对大家进行本体论的设计,或者叫本体论建模的工作,有相关的一些参考。
今天的分享就到这里,再见。
注:暂时不提供上面的演示应用的源代码,因为还在完善中。同时昨天我和我们架构师正哥沟通的我的一些想法,一个更加完整的构建思路正在逐步细化中,核心大家可以理解为本体+AI构建一个新的驱动应用开发构建的新范式。