从领域驱动到本体论：AI 时代的架构方法论变了

2026-03-21 6 纸飞机账号购买

在过去的两年时间当中，绝大多数的团队引入人工智能的途径大致相同，也就是代码补全、自动测试以及问答系统，其效果十分显著，能够立刻见到成效。然而，一旦着手尝试将人工智能推进至核心的业务逻辑层面，问题便随之出现了。

设想一个你或许碰到过的情形，有着汽车零配件销售系统，有客户下达了 100 个滤清器的订单，库存被显示为 120 件。AI 的判定是能够发货。然而业务人员瞧一眼便晓得不对劲，这批库存之中有预留件，这个客户仍处于信用审核流程里，并且这个渠道的订单必须经过额外审批。那些与发货决策相关的关键信息去往何处了呢？它们并非遗失了，只是分散于代码逻辑里，在流程引擎里，甚至在老员工的经验里。AI 能够读取字段值，却读不懂背后那套约束体系。所以，AI 缺的不是数据，是对企业运作方式的理解。

一、为什么你的系统对 AI "不透明"

从技术层面来讲，这个问题的根源清晰明了，如下：长久以来，我们运用代码去表达业务规则，而非借助结构化的模型。举例而言，像这样一条规则，即“订单金额超过 10 万需要总监审批”，它可能会以这些形式呈现：

每一种都能够正常地运行，可是对于AI来讲，这些全部都是不能够被解析的黑盒。它既没有办法知晓规则的存在，更加没有办法在执行之前判断边界条件。所以，你的系统对于AI是不透明的，很大概率不是由于数据不够，而是因为业务语义没有被显式地建模。

二、DDD 早就看到了这个问题

二十年前就已提出解决显式建模正确答案的领域驱动设计（DDD）表明，软件应当围绕领域模型构建，而非围绕技术分层构建。领域驱动设计（DDD）在战略层面着重强调统一语言以及限界上下文，在战术层面给出了诸如Entity、Value Object、Aggregate、Domain Event等一系列建模模式，其核心目标是使代码切实贴近业务现实。

理念无可挑剔，然而在工程实践当中，DDD极具难度去持续坚守，缘由是涵盖多个层面的。

存在着一种情况，那就是缺乏具备结构化特征的工程机制，在这种机制下，DDD尝试借由“约定和纪律”去维系模型的一致性，然而它却并未提供那样一种手段，也就是能够将规则以显明的方式呈现出来，并且使其工具化的手段。聚合边界、业务规则以及状态约束，最终全都归结到代码之中，可是文本形式的代码并非是用以表达这些内容的优良载体，像Lint等静态检查工具也没办法实现自动化检查。规则以及约束实际上是分散于各个层次的，新加入团队的成员根本看不懂，进行改动时风险极高，如此一来，知识随着人员的流动而流失就难以避免了。延续不断积累着协作成本，统一语言并非一次性就能完成的工作，而是需要业务专家跟开发者进行长期的协作来加以维护。处在交付压力的状况下，这样的协作纪律基本上难以持续保持。业务所使用的是一套词汇，而 IT 运用的却是另外一套概念，在翻译的过程当中核心语义不知不觉地流失了，导致模型渐渐跟现实相互脱节。存在过度应用所产生的反效果，DDD 在复杂业务领域当中价值是最高的，然而团队常常针对简单模块也套用了一整套开发模式，从而增加了不必要的复杂度，反倒引发出对整套方法论的抵触情绪。

最终呈现的结果大致相同但存在细微差别：经过好几轮的反复迭代之后，选择放弃建模方面的约束条件，业务所应遵循的规则又再次回归到代码以及 SQL 之中，领域所蕴含的语义又一次变得零散且隐晦难以察觉。从很大程度上来说，DDD 所面临的问题从来都不是其方向出现错误问题，而是在于在缺乏平台给予支撑的状况之下，要维持它就需要那么多方持续不断地投入成本实在是太难了。

三、本体论把语义层提升为平台基础设施

以软件服务提供商身份在AI时代迅速兴起的Palantir，在其Foundry平台里引进了本体论这一概念，本体论是知识工程领域的术语，它把企业的业务世界当作一个需要被形式化描述的“知识领域”来处理，这种引进可被视为DDD在工程方面的一次落地升级，是这样的情况。依照官方文档给出的定义，Ontology属于组织的数字孪生，它是一个处于数据集以及模型等数字资产之上的语义层，借助把数据集与模型映射至对象类型、属性、关联类型还有操作类型，进而构建出组织世界的完整图象。从工程角度来讲，Ontology的核心构件涵盖：

相较于DDD，Ontology的关键区别在于，DDD的模型一致性需开发者于代码层面手工去维护，而Ontology将此提升至平台本身。相关规则的构建不再靠着代码实现来“还原”，却是直接变为系统运行的基础元数据。按照葡萄城低代码白皮书的表述，这恰是元数据驱动的核心价值所在，它把系统的关键规则以及约束从隐性代码里解放出来，借助结构化元数据进行显式表达，从而让其成为可管理、可验证、可追踪的工程资产。

另外，于互联网媒体同行业专家们探讨 Ontology 之际，多数人所留意的是“怎么去建模”，而另一种关键能力常常被看轻，此即决策捕获（Decision Capture）。该能力直接把建模由静态转变为动态，不仅留意规则的设计，还能够监测规则的实际施行，为深入理会这些规则、持续改进这些规则奠定基础。具体来说，把组织里用户的决策当作数据捕获下来，一个用户获取的洞察能够反过来对另一个用户的决策产生影响，操作人员在照着本体论的应用中做出的每一项决定，都被写回到模型之中，从而形成持续不断的反馈回路。

四、本体论对 AI 落地的实际意义

从AI工程的角度去看，Ontology解决的可是大模型自身没办法解决的问题么，此问题为，”于当下企业里，在何种约束条件之下，能够针对哪些对象，去施行哪些操作“。如此一来，AI（其主要存在形式为智能体）便能够直接关联到那些正驱使组织运行的基础构件以及流程之上，不需要经由额外的适配器或者胶水代码，便能够直接于核心应用以及系统内里达成治理、发布以及落地，并且能够支持批处理、流处理或者查询驱动等多种服务形式。这是一个相当关键的工程分界点呀：

处于大型企业的范畴而言，伴随数据集在不停扩大，仪表盘数量持续增多，应用数量也日益增长，光是弄明白哪些数据资产是存在的或者应当被使用，就得投入越来越多的精力，新项目老是在“重新发明相同的事物”，并非去复用已有的资产。然而 Ontology 却开辟了一条相反的途径，只要针对进入平台的新数据开展一次数据集成，往后所有的应用以及用例能够直接依据现有的 Ontology 来构建，使得应用开发者能够把精力汇聚在业务问题以及用户工作流方面，而非数据整理上面。无论这个应用是传统的Web表单，还是移动端APP，又或是AI智能体，对于技术管理者来讲，这是一种切实存在的“规模经济”效应，Ontology构建越是完备，每一个新用例的落地成本便越低。

五、总结

AI若要真正参与企业运营，其前提仅有一个，即企业自身必定是能够被理解的，这意味着核心业务实体具备统一的语义定义、操作约束以及以可查询的模型形式存在，且每一个业务决策都被结构化地记录下来，倘若做不到这三点，那么AI所能做的仅仅是生成代码、回答问题，始终停留在工具层面，无法进入决策层面，也不能对结果负责。

这件事的难点并非在于AI，而是在于企业自身，大多数系统的业务规则分散于代码分支之中，存在于流程引擎之内，还留存于老员工的经验里，这并非数据方面的问题，乃是建模层面的问题，企业从来都未曾被当作一个能够执行的结构去进行设计，虽说，DDD早在二十年前就已然指明了正确的方向，然而受限于工程成本，一直都难以大规模地实现落地。今日，本体论方法论以及元数据驱动型平台，将 DDD 的理念，从“设计约定”提升为“平台基础设施”，业务对象、关联关系、操作约束，进行统一建模，能够直接驱动系统运行，AI 可在这一结构上，直接理解规则、执行决策、写回反馈。这的确是方法论与技术工具的一次实质性升级，并非仅仅换了一套术语标点。

对架构师来讲，将本体论予以引入并加以实施，这表明关注点得往上进行转移。以往我们所优化的是分层、解耦以及性能，而如今更为根本的问题在于企业是不是被精准建模了呢？代码编写得多么出色那是执行层的事情，业务建模得多么准确才是架构层的事情。协助企业把自身建模清晰，这是架构师在人工智能时代充分施展自身经验与技术的契机，也是助力企业迅速迈入智能化时代、打造“人工智能+”的加速工具。

说明：本文关于本体论的相关内容，是基于Palantir官方文档的，关于DDD的相关内容，是基于Eric Evans所著的《Domain-Driven Design》以及业界共识的，关于元数据驱动的相关内容，是参考葡萄城的《低代码技术白皮书——从软件工程视角理解低代码的价值、边界与演进路径》的。