从领域驱动到本体论，AI时代的架构方法论变了，这难道不是一种新的趋势吗？

过去两年，大多数团队引入 AI 的路径大同小异：代码补全、自动测试、问答系统，效果立竿见影。但一旦尝试把 AI 推进到核心业务逻辑，问题就来了。 举个你可能遇到过的场景，汽车零配件销售系统，客户下了 100 个滤清器的订单，库存显示 120 件。AI 的判断是可以发货。但业务人员看一眼就知道不对，这批库存里有预留件，这个客户还在信用审核流程中，而且这个渠道的订单必须走额外审批。这些发货决策相关的关键信息哪里去了？它们并没有丢失，只是分散在代码逻辑里、流程引擎里、甚至老员工的经验里。AI 能读到字段值，但读不懂背后那套约束体系。所以，AI 缺的不是数据，是对企业运作方式的理解。 一、为什么你的系统对 AI "不透明" 技术上来说，这个问题的根源很清楚：我们长期以来用代码来表达业务规则，而不是用结构化的模型。比如一条“订单金额超过 10 万需要总监审批”的规则，可能以这些形式存在： 藏在某个 Service 方法的 if 分支里 写在 Camunda 或 Activiti 流程定义的某个网关条件上 硬编码在前端表单的校验逻辑中 每一种都能正常运行，但对 AI 来说，这些都是不可解析的黑盒。它既无法知道规则的存在，更无法在执行前判断边界条件。所以，你的系统对 AI 不透明，大概率不是因为数据不够，而是因为业务语义没有被显式建模。 二、DDD 早就看到了这个问题 领域驱动设计（DDD）在二十年前就提出了解决显式建模的正确答案：软件应该围绕领域模型构建，而不是围绕技术分层。DDD在战略层面强调统一语言和限界上下文，在战术层面提供了 Entity、Value Object、Aggregate、Domain Event 等一套建模模式，其核心目标是让代码真正贴近业务现实。 理念无懈可击，但工程实践中，DDD 很难持续坚持。原因是多层面的： 缺乏结构化的工程机制：DDD 试图通过“约定和纪律”维持模型一致性，但没有提供将规则显式化、工具化的手段。聚合边界、业务规则、状态约束，最终都落回到代码里，而文本化的代码并不是表达这些内容的好载体，Lint等静态检查工具也无法自动化检查。规则和约束事实上散落在各层，新加入团队的成员读不懂，改动风险高，知识随人员流动而流失就在所难免。 协作成本持续累积：统一语言不是一次性工作，需要业务专家与开发者长期协作维护。在交付压力下，这种协作纪律几乎无法坚持。业务用一套词，IT 用另一套概念，翻译过程中核心语义悄然流失，模型逐渐与现实脱节。 过度应用的反效果：DDD 在复杂业务域中价值最高，但团队往往对简单模块也套用了全套开发模式，增加了不必要的复杂度，反而引发对整套方法论的抵触。 最终结果大同小异：几轮迭代后放弃建模约束，业务规则重新回到代码和 SQL 里，领域语义再次变得分散隐性。很大程度上讲，DDD 的问题从来不是方向错，而是在没有平台支撑的情况下，维持它所需的多方持续投入太难了。 三、本体论把语义层提升为平台基础设施 AI时代快速崛起的服务商 Palantir，在其 Foundry 平台中将本体论（Ontology，知识工程领域的术语，指把企业的业务世界当作一个需要被形式化描述的“知识领域”来处理）的概念引入数字化建设，可以看作是 DDD 的一次工程落地升级。按照官方文档的定义，Ontology 是组织的数字孪生，是一个坐落在数据集和模型等数字资产之上的语义层，通过将数据集和模型映射到对象类型、属性、关联类型和操作类型，构建出组织世界的完整图景。 从工程角度，Ontology 的核心构件包括： Object Type（对象类型）：定义企业中的实体或事件，如订单、客户、设备 Property（属性）：每个对象的特征字段，包含丰富的元数据和格式规则 Link Type（关联类型）：对象之间的关系定义，类似数据集的 Join，但被显式建模 Action Type（操作类型）：定义用户可以对对象执行哪些变更操作，以及相应的约束和副作用 Function（函数）：绑定到 Ontology 的代码逻辑，可以接受对象作为输入，直接在平台中执行业务计算 Interface（接口）：描述对象类型的结构和能力，支持多态建模 Ontology 区别于 DDD 的关键在于，后者的模型一致性靠开发者在代码层面手工维护，而前者把这一层提升到平台本身。规则不再依赖代码实现来“还原”，而是直接成为系统运行的基础元数据。用葡萄城低代码白皮书的说法，这正是元数据驱动的核心价值，将系统的关键规则与约束从隐性代码中解放出来，通过结构化元数据显式表达，使其成为可管理、可验证、可追踪的工程资产。