从领域描述到本体：AI时代系统设计模式的范式转变

在软件开发领域，领域驱动设计（Domain-Driven Design，简称DDD）作为一种解决复杂业务系统结构设计的实用方法论，已经沿用二十余年。其核心价值在于「收敛」——通过划分限界上下文，将团队精力聚焦在特定业务边界内的对象特性与行为上。这种「领域描述」的设计模式在过去信息化时代表现出色，我们所做的绝大多数信息系统，其实都是在这种模式下解决某个特定边界内的局部应用问题。强模式与单一领域的结合，为开发团队带来了极大的便利与确定性。

概述

然而，当大语言模型开始深入企业应用场景时，这种传统模式正在面临前所未有的挑战。企业在跨系统应用AI方面的需求已经从可选项变成了强刚需。单系统的局部优化——如用AI帮客服写摘要、自动填单——已经无法带来更多的架构红利。真正迫切需要的能力，是让AI能够参与跨系统的全局复杂决策。例如，当AI需要分析一个产品的全生命周期成本时，系统需要同时调阅研发系统的设计维度、供应链系统的库存维度、以及财务系统的预算维度。这时候，原本依靠边界隔离的舒适状态被彻底打破。

传统技术路径的局限性

为解决跨系统数据整合问题，目前行业主要存在三种演进路径，但在面对全局AI应用时都表现出明显的局限性。首先是传统的数据仓库与湖仓架构。现代湖仓一体架构在底层很好地解决了海量数据的物理汇聚、清洗与结构化查询，但数仓的天然使命是服务于报表、分析和确定性的统计指标。它主要表达的是技术视角的表结构，而非业务视角的全局统一概念。当上游业务因需求变化不断涌现出新的数据维度时，仅靠数仓层去动态对齐这些业务概念，在工程性价比和维护成本上面临巨大挑战。

裸Text2SQL的语义困境

其次是缺乏统一语义层支撑的裸Text2SQL方案。随着大模型的兴起，许多团队尝试直接将各系统的物理表结构和注释喂给模型，依赖Text2SQL实时生成查询代码。这种方案的根本瓶颈在于缺乏统一的语义空间。如果缺乏语义层支撑，直接让AI面对底层为了存储和事务效率而设计的缩写字段、关联表和分表逻辑，本质上是在用「物理结构的概率猜测」去对抗「业务要求的确定性」。在多系统并存的环境中，AI无法自发消除同义不同名、同名不同义的语义噪音，每一次实时的SQL调用都存在概率性的出错风险。

本体模式：跨系统整合的解药

既然物理搬运、裸Text2SQL、以及将图数据库当成主库的路线都存在局限，系统设计模式就需要从关注局部边界的「领域描述」，扩展到关注全局逻辑映射的「本体」模式。本体并不直接存储或描述数据库中的具体记录，它定义的是企业业务世界中那些最基础的业务概念和它们之间的逻辑关系。在静态语义层面，本体需要定义两类最稳定的内容：核心概念（Concepts）——如人、产品、合同、设备等企业最基础的客观业务实体；以及概念间的逻辑关系（Relations）——如包含、从属或关联关系。底层的物理表结构可以随着业务升级持续演化，但这些核心概念本身以及它们之间的业务逻辑关系，通常是跨越系统周期、保持长久稳定的。

如有侵权，请联系删除。