AI时代，DDD与Ontology建模有何不同？

相关文档，请提前阅读：

• 简单了解AI时代DDD领域驱动设计
• AI时代的大数据底层结构：Palantir-Ontology详细说明

一、双维建模：逻辑深度与语义广度

复杂业务程序的建模方法与开发方式可以分为两条路线：

• DDD 范式以应用代码开发为主。利用充血对象与限界上下文，在微服务内部建立精确的业务规则。其主要在于“逻辑的深度”。目前的主流开发范式，
• Ontology 范式以网站语义层为载体，通过 ObjectType、LinkType 与 ActionType 建立跨程序的全局知识图谱。其主要在于“语义的广度”。因为Palantir走红而被业界研究。

flowchart TB BIZ::的观点是，root 至于L1::，layer1 L2::的观点是，layer2 DDD::的观点是，ddd 至于ONTO::，onto BIZ --> L1 BIZ --> L2 L1 --> DDD L2 --> ONTO classDef root fill:#37474F,stroke:#,stroke-width:2px,color:#ECEFF1 classDef layer1 fill:#FFE0B2,stroke:#EF6C00,stroke-width:2px。color:#BF360C classDef layer2 fill:#B2DFDB,stroke:#00796B,stroke-width:2px,color:#004D40 classDef ddd fill:#FFCDD2,stroke:#C62828,stroke-width:2px,color:#B71C1C classDef onto fill:#C8E6C9,stroke:#2E7D32,stroke-width:2px,color:#1B5E20

• DDD 聚焦局部确保在一个特定的限界上下文内，代码能忠实反映业务意图。
• Ontology 聚焦全局确保在整个公司环境内，不同程序对“客户”、“资产”等主要概念拥有统一的定义、权限与审计链路。

误用二者可能导致严重问题！比如用 DDD 坚持把全公司共享概念各写一套代码；或试图用 Ontology 强行表达单聚合根强一致性事务——都是典型反例！正确做法是分层协作：让 DDD 负责单聚合根内部规则，让 Ontology 负责跨程序语义治理！ 具体见《应用结合》章节，您当前面临什么问题？是需要更强规则表达，还是需要更强跨程序协作？请明确需求再选择，误选将带来巨大技术债！

二、概念程序对比

术语对照表

实体 Entity ObjectType + 实例

值对象 Value Object Property 上的 Value Type

关系 实体 / 聚合根间的引用 LinkType 警告：这里是最容易出错点之一！很多人错误认为 Link 是简单连接线——它是独立存在并可附加属性/校验/权限的一等公民！比如供应链中的"订单-物流公司"关系不仅包含连接还包含运费/时效约束！如果忽略这一点会导致查询功能无法实现！您必须清楚这个区别才能正确使用！否则将陷入"只能做简单关联查询无法支持复杂场景"困境！这是区分高级架构师和普通工程师最关键点之一!

警告这方面，这绝不是简单两张表之间外键关系!实际案例中看到很多失败案例就是因为忽视Link作为独立对象特性，最终导致无法满足客户多维度查询需求!例如某金融公司因错误理解Link特性，最终不得不放弃Ontology回到传统关系数据库... 这种错误成本极高!请重视，

添加评论

在这里你可以添加HTML评论。