本体 × DDD × AI

ONTOLOGY · DOMAIN-DRIVEN DESIGN · AI // 把概念说清楚的力量

> 1993 年知识工程师 Gruber 说：本体是"概念化的明确规范"；2003 年 Evans 在 DDD 里说：让开发者与领域专家共用一套统一语言、按限界上下文切分边界。两条路其实是同一件事的两个精度档位——给真实世界建共享的概念模型：本体走形式化路线（OWL 公理可推理），DDD 走工程化路线（代码可执行）。LLM 时代它们突然合流：说清楚概念的回报率暴涨——CLAUDE.md/AGENTS.md 是统一语言的 prompt 化身，JSON Schema 是轻量本体，Bounded Context 是 agent 的上下文边界，本体接地的 RAG（GraphRAG/OG-RAG 一族）把"幻觉"从祈祷问题变成架构问题。模型越强，越贵的是没说清楚的那部分。

SUBJECT: 知识工程 · 软件设计 · AI 架构 FILE: cards/ontology-ddd-ai SINCE: 1993 本体 / 2003 DDD / 2024 合流 BUILD v1.0

Principle — 原理与来源

本体 × DDD × AI // 同一问题的三条等高线

同一个世界，三种精度：可推理 / 可执行 / 可生成

本体（OWL 公理）· DDD（领域代码）· AI（Schema + 规约 + 上下文）

"An ontology is an explicit specification of a conceptualization." — Gruber, 1993

本体（Ontology）：词借哲学（"存在的系统化说明"），计算机语义由 Tom Gruber 1993 一锤定音："概念化的明确规范"——用类（Class）、属性（Property）、关系（ObjectProperty）、公理（Axiom：如传递性、不相交性）显式定义一个领域里"有什么、什么关系、受什么约束"。W3C 语义网栈（RDF 三元组 / OWL / SPARQL）让它可序列化、可推理：新实例喂进公理系统能推出你没写的事实、查出你没看见的矛盾。

DDD（领域驱动设计）：Eric Evans 2003《Domain-Driven Design》。两大支柱：统一语言（Ubiquitous Language——开发者与领域专家共用一套词汇，代码、文档、对话全用它，" Within a bounded context, you will have a coherent dialect of the ubiquitous language"）与限界上下文（Bounded Context——同一个词在不同边界内含义不同，模型只在自己边界内求一致，边界之间用上下文映射（Context Map）协作：防腐层、共享内核、客户-供应商）。Evans 本人 20 年回顾：战略设计这半部（语言/边界/映射）老化得最好，战术模式（Entity/Repository 等）反而是次要半部。

为什么在 AI 开发里合流：LLM 的输出质量由输入的概念清晰度决定——模糊进，幻觉出。于是三个传统工具被重新定价：① 统一语言 → 上下文工程：CLAUDE.md/AGENTS.md 本质是写给 agent 的术语表与规约，是 Ubiquitous Language 的 prompt 形态；② 本体 → 结构化输出与接地：JSON Schema/Pydantic 是轻量本体（类型+约束+枚举），GraphRAG（微软 2024）用 LLM 抽知识图谱做检索接地、OG-RAG（2024）更进一步用预定义本体约束生成——幻觉率显著下降；③ 限界上下文 → agent 边界：每个 agent 的上下文窗口就是一个 bounded context，agent 间的协议就是 context map，防腐层 = prompt 适配器（隔离外部模型的词汇污染）。

① "本体"不是玄学词——计算机语境下是 Gruber 1993 的定义（概念化的明确规范：类/属性/关系/公理），与哲学的"存在论"是借词关系；把"本体论"当"本质论"用是范畴错误。 ② DDD ≠ 战术模式集——Evans 本人回顾：Entity/Repository/Aggregate 那半部是次要的，统一语言 + 限界上下文 + 上下文映射才是 20 年后依然锋利的部分；把 DDD 等同于"分层架构+贫血模型修复"是买椟还珠。 ③ 本体 ≠ 知识图谱——本体是 schema（概念层：类与公理），KG 是实例数据（A 实例化 B 的关系）；GraphRAG 让 LLM 自由抽图（无本体约束，快但噪声高），本体接地的抽取（OG-RAG 一类）慢一点但一致性与可推理性高——选哪个看领域稳定性。 ④ "AI 时代 DDD 过时了"是误判——恰好相反：LLM 把"说清楚概念"的边际收益放大了一个数量级（同一份规约，弱模型产出及格、强模型产出优秀），Evans 解决的"概念混乱税"在多 agent 协作里加倍出现。 ⑤ 本体 ≠ 数据字典 / ER 图——差别在公理与推理：本体声明"部分-of 传递""A 与 B 不相交"，推理机能自动检出违反者；把 OWL 当表结构文档用，等于买了推理机只用外壳。 ⑥ 上下文工程不是新玄学，是 DDD 的运行时复活——"给 agent 喂什么上下文"的工程学，等价于"限界上下文里放哪个模型"；会做 context mapping 的团队，agent 编排天然上手——旧地图恰好覆盖新领土。

Apply — 用在哪里

上下文工程CLAUDE.md/AGENTS.md 按统一语言来写：领域术语表 + 不变量 + 边界说明——每个术语歧义都在污染每一次生成；术语定版比 prompt 技巧复利大得多。

RAG/接地向量检索是"语义近邻"，本体接地是"语义精确"：领域稳定且术语密集（医疗/法务/制造）用本体约束的 GraphRAG，领域开放且快变用自由抽图——先问歧义成本再选架构。

结构化输出把 JSON Schema 当本体设计：类型、枚举、约束、不相交性（discriminated union）都写进 schema——校验在解析层完成，别把类型判断留给生成层的"自觉"。

多 Agent每个 agent 一个限界上下文（自己的词汇与工具），agent 间走显式协议（context map），跨模型/跨厂商调用加防腐层（prompt 适配器隔离外部词汇污染）——DDD 的老图直接套新架构。

领域建模事件风暴（Event Storming）+ LLM：人负责领域事件与统一语言（判断"什么重要"），模型负责汇总成实体/关系/公理草稿（生成"怎么写"）——建模的品味留在人，誊写的体力交给机。

Simulate — 三层映射实验室 × 接地收益沙盘

双视角实验室 // 点概念看三个传统怎么各写一遍；滑接地深度看幻觉风险曲线

视角 A：本体 / DDD / AI 三列对照——同一概念的三种精度写法；视角 B：本体接地深度与幻觉风险的收益曲线（示意模型）

本体层（形式化）

DDD 层（工程化）

AI 层（生成侧）

点击任意一列的概念，看三层对应物与差异说明。

■ 本体（可推理） ■ DDD（可执行） ■ AI（可生成）

Personal Takeaways — 个人启示 · 03

歧义是复利的成本项

一个没定义的术语，被写进规约、复制进 prompt、放大进每次生成、再被人审时各自理解——歧义按交互次数复利。术语表不是文档洁癖，是全链路的降息操作；先把十个核心词定死，胜过调一百次 prompt。

模型越强，概念越贵

LLM 把"写清楚"的回报率拉高了一个数量级：同一份 schema，强模型能兑现到接近公理级的一致性——瓶颈从"实现能力"转移到"定义能力"。投资方向相应改变：建模功夫（本体思维 + DDD 边界感）现在是 AI 团队回报率最高的技能。

边界先于模型

限界上下文教的事在 agent 时代加倍成立：每个 agent 只在自己的概念边界内求一致，跨边界必须走显式协议——先划清谁管什么词，再决定用什么模型。多数"多 agent 混乱"的根源不是模型弱，是 bounded context 没画。