从“领域描述”到“本体”——AI时代的系统设计模式探讨

推荐语

从“领域描述”到“本体”，探索AI时代如何整合数据孤岛，赋能全局智能决策。

核心内容：
1. 传统“领域描述”设计模式的优势与局限
2. AI时代对跨系统、多维数据整合的迫切需求
3. 面向未来的“本体”设计模式探讨

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

作为一个拥有二十多年研发经验的工程师，我更倾向于将 DDD 视为一种解决复杂业务系统结构设计的实用工具。它最核心的价值在于“收敛”——通过划分限界上下文，逼着团队将精力聚焦在特定业务边界内的对象特性与行为上。用合理的工程成本满足当前业务的需求。从本质上看，传统信息化时代我们所做的绝大多数信息系统，其实都是在这种“领域描述”的设计模式下，去解决某个特定边界内的局部应用问题。

强模式与单一领域的“舒适区”

面向特定领域开发的系统，其内部的领域对象通常有着明确的属性定义和行为。在技术落地时，我们天然习惯于使用支持强模式（Strong Schema）的关系型数据库来承载这些数据。在开发期就将字段、表结构和约束条件盖棺定论。这种确定性不仅能有效降低系统的开发难度，也能带来符合预期的并发性能和业务落地效果。

然而，这种长期的舒适，建立在一个常常被忽略的底层事实之上：我们在“领域描述”里精心构建的对象，往往只是那个客观实体在特定场景下的一个切面。真实世界中的核心业务概念，是随着企业技术手段和业务需求的提升，不断增加认知维度的。

概念本身通常保持稳定，但刻画它的维度却在随着业务演进而无限变化。

在常规的企业架构中，不同的职能部门各司其职，每个子系统都专注于其特定的“领域”。同一个业务实体，在不同的“领域描述”下会呈现出完全不同的切面：

• 人力资源系统在进行领域建模时，抽取的是“薪酬、绩效、工龄”等管理维度，组成了“员工”这个强模式对象；

• 医疗系统则需要抽取“血型、病史、过敏源”等生物维度，组成了“患者”这个强模式对象。

这种“领域描述”模式的合理性，在于它允许我们在特定的业务边界内，切断对其他无关维度的纠缠，只锁定当前业务关心的那几个字段，从而最大程度地降低开发和存储的复杂度。在过去，靠着系统和数据库的边界隔离，大家各管各的维度，互不干扰。

AI 时代的破局：跨系统多维数据的全局需求

然而，随着企业数字化走向深水区，特别是大语言模型引入后，企业跨系统应用 AI 的需求已经变成了现实的强刚需。

今天，单系统的局部优化（如用 AI 帮前台客服写个摘要、自动填个单据）已经无法带来更多的架构红利。企业真正迫切需要的能力，是让 AI 参与跨系统的全局复杂决策。

例如，AI 想要分析一个产品的全生命周期成本，系统需要同时调阅研发系统的设计维度、供应链系统的库存维度、以及财务系统的预算维度。

这时候，原本依靠边界隔离的舒适状态被打破，“领域描述”模式面临一个系统级的难题：散落在各个孤岛系统中的业务表，各自攥着同一个概念的不同维度，我们应该如何优雅地将这些跨系统、跨时代的维度整合在一起，提供给上层 AI 进行准确的全局推理？

如果此时系统设计依然沿用老路，仅仅关起门来在某个单一系统的代码里去打补丁，那它在跨系统 AI 面前，依然只是一个更时髦的、孤立的语义烟囱。

跨系统多维整合的三种常见技术局限

为了缝合这些散落在各个独立系统中的数据维度，目前行业中主要存在三种演进路径。但在缺乏顶层统一业务认知层的支撑时，它们在面对全局 AI 应用时都表现出了局限性：

1. 传统的数据仓库与湖仓架构

现代湖仓一体架构（如 Lakehouse、Iceberg、Data Vault 等技术）在底层很好地解决了海量数据的物理汇聚、清洗与结构化查询。但数仓的天然使命是服务于报表、分析和确定性的统计指标。数仓的局限不在于强模式（Strong Schema），而在于它主要表达的是技术视角的表结构，而不是业务视角的全局统一概念。当上游业务因需求变化不断涌现出新的数据维度时，仅靠数仓层去动态对齐这些业务概念，在工程性价比和维护成本上面临巨大挑战。

2. 缺乏统一语义层支撑的裸 Text2SQL 方案

随着大模型的兴起，很多团队尝试直接将各系统的物理表结构和注释喂给模型，依赖 Text2SQL 实时生成查询代码。

Text2SQL 技术本身没有问题，但缺少统一的语义空间是根本瓶颈。如果缺乏语义层支撑，直接让 AI 面对底层为了存储和事务效率而设计的缩写字段、关联表和分表逻辑，本质上是在用“物理结构的概率猜测”去对抗“业务要求的确定性”。在多系统并存的环境中，AI 无法自发消除同义不同名、同名不同义的语义噪音，每一次实时的 SQL 调用都存在概率性的出错风险。

3. 将图数据库当作全量业务存储

在意识到需要整合复杂概念关系时，另一种做法是引入图数据库。图数据库非常适合处理图拓扑网络中的深度路径穿透和关联检索，但它本身只是一个存储引擎，并不天然等价于企业的业务逻辑关系，更不意味着必须承担全量业务数据的存储职责。很多团队错误地把图数据库当成了企业统一的物理存储平台，试图将所有业务数据打碎成三元组强行集中存放，这不仅带来了不必要的链路损耗，也容易陷入工具错配的性能瓶颈。

解药：“高维语义骨架”--本体模式

既然物理搬运、裸 Text2SQL、以及将图数据库当成主库的路线都存在局限，系统设计模式就需要从关注局部边界的“领域描述”，扩展到关注全局逻辑映射的“本体（Ontology）”模式。

如果我们要把本体作为 AI 时代的通用逻辑层，那么在具体的设计落地中，它究竟应该定义什么？

我们需要明确：本体并不直接存储或描述数据库中的具体记录，它定义的是企业业务世界中那些最基础的业务概念和它们之间的逻辑关系。

在系统架构中，本体层应该保持足够的职责克制。在静态语义层面，它首先需要定义两类最稳定的内容：

• 核心概念（Concepts）：如人（Person）、产品（Product）、合同（Contract）、设备（Device）等企业最基础的、不随具体系统消亡而湮灭的客观业务实体。

• 概念间的逻辑关系（Relations）：如包含、从属或关联关系。

底层的物理表结构可以随着业务升级持续演化、不断追加和裁剪新的属性维度（比如 HR 系统追加绩效字段、医疗系统追加生物体检字段），但这些核心概念本身，以及它们之间的业务逻辑关系，通常是跨越系统周期、保持长久稳定的。

在 AI 时代的系统设计中，本体不应该扮演物理存储，它其实是一套用于映射和包容无限维度的逻辑骨架。

有了这层纯粹的逻辑层，再配合现代语义层（Semantic Layer）技术，大模型就不需要去盲目猜测生硬的底层物理表。此时，Text2SQL 变成了基于统一语义空间的精准翻译。它把 AI 面临的概率幻觉，变成了系统架构上的确定性映射。

系统模式的突围

从“领域描述”到“本体”，本质上是系统设计模式在空间和灵活性上的一次解耦。

我们在做单一系统开发时，为了追求效率、并发和业务落地的准确性，极其依赖 DDD 的“硬边界”和强模式（领域描述）；但当我们要站在企业全局做跨系统 AI 应用时，为了追求弹性和维度的无限演进，又极其需要 本体的“弱模式”和高维抽象（本体建模）。

这导致绝大多数企业的技术架构，都卡在了业务团队死守系统边界、数据团队疲于硬编码对齐语义的尴尬胶着期。

业务边界（领域描述）必须存在，未来的可扩展性（本体模式）也必须满足。

在工程性价比和演进弹性的双重倒逼下，AI 时代的系统设计，必然趋势是告别传统的“物理大一统”执念，走向“语义逻辑统一、物理分布式”的去中心化架构。

这并不是某种理论空想，而是正在发生的产业趋势。从微软大力推行的 Fabric 架构和 OneLake 理念就可以看出，行业正在全面转向“数据就地保留、逻辑快捷对齐”的解耦路线。

我们需要在系统顶层将本体的认知周期、领域的业务演化周期、以及物理实体的生存周期彻底剥离开来。用本体作为 AI 全局协同的统一语义坐标，用 DDD 作为各业务系统高效落地的物理边界。这样，才能在保留子系统高并发事务性能的同时，真正拿到打开企业全局智能的钥匙。