📰 来源: 博客园
探讨领域驱动设计（DDD）与本体论建模（Ontology）之间的本质差异，搞清其背后的理论体系和运行机制。
一、双维建模：逻辑深度与语义广度
复杂业务系统的建模方法与开发方式可以分为两条路线：
二者在表面上都涉及“对象、关系与行为”，但其实际解决的问题层级截然不同：
误用二者的典型代价是：用 DDD 做全企业模型会导致架构僵化；而用 Ontology 做纯应用框架则会显得过于沉重。只有各司其职，才能发挥其最大价值。
二者都有一套自己的"基础词汇"，下面把对齐项放在一起看。
2.2 抽象层次的差异
DDD 的载体是"程序"——业务模型靠源代码表达，靠编译器和测试保证一致性，部署到 JVM / 容器中执行。
Ontology 的载体是"平台"——业务模型靠元数据声明（ObjectType / LinkType / ActionType），由平台保证一致性，由专门的语义层服务（如 OSv2、OMS、Funnel）执行。
这一抽象层级的差异，决定了二者在"表达力 / 工程成本 / 跨系统统一性"上的所有不同。
二者背后的本体观（哲学层面）截然不同。
3.1 实体本体论 vs 关系 / 过程本体论
DDD 继承了 OOP 的实体本体观——对象是建模的中心，关系靠对象引用（聚合内）或 ID 引用（聚合外）表达；行为是对象的方法。
Ontology 站在关系本体观一侧——LinkType 是独立的一等公民，可以挂属性、可以被查询、可以参与 Action；对象是"关系网络中的节点"，而不是建模的中心。
工程后果：DDD 适合表达"对象内部的强一致性规则"；Ontology 适合表达"对象之间的复杂关系网络与跨域决策"。试图用 DDD 表达"任意两个对象间的 N 种关系且关系本身有属性"，会让聚合根膨胀；试图用 Ontology 表达"聚合内部 7 条不变量的强一致性事务"，会发现它的最终一致性语义不直接支持。
3.2 Palantir 的三层哲学（认识论与实践论的延伸）
Ontology 不仅是本体论的实现，Palantir 把它扩展为"本体—认识—实践"三层（详见 ../ontology-research/技术原理介绍.md 1.2 节）：
DDD 主要回答本体论与认识论，把"实践论"留给业务方与应用层。Ontology 的雄心更大——它要把三层合到同一个语义平台、同一套权限、同一条审计链路上。
下面把二者在工程上的具体形态摆在一起，差异立刻清晰。
4.1 "实体 + 关系 + 行为"的写法对比
DDD 写法（Java / Spring Boot）：
// 实体（聚合根）
public class Vehicle {
private VehicleId id;
private String model;
private VehicleStatus status;
private List<RequiredPart> requiredParts; // 聚合内强引用
private ProductionLineId assignedLine; // 聚合外用 ID
public void startProduction(ProductionLine line, InventoryView inventory) {
if (!inventory.hasAllParts(this.requiredParts))
throw new IllegalStateException("缺料");
if (!line.isIdle())
throw new IllegalStateException("产线繁忙");
this.status = VehicleStatus.IN_PRODUCTION;
this.assignedLine = line.getId();
addDomainEvent(new VehicleStartedProductionEvent(this.id, line.getId()));
}
}
Ontology 写法（Palantir 风格的伪代码，详见 ../ontology-research/数据存储与使用方式对比.md）：
// ObjectType 声明
{ "ObjectType": "Vehicle", "properties": { "model": ..., "status": ... } }
// LinkType 声明（关系是一等公民）
{ "LinkType": "REQUIRES_PART",
"from": "Vehicle", "to": "Part",
"properties": { "mandatory": "boolean", "quantity": "integer" } }
// ActionType 声明（行为是一等公民）
{ "ActionType": "startProduction",
"subject": "Vehicle",
"params": { "line": "ProductionLine" },
"preconditions": [
{ "rule": "allRequiredPartsInStock(vehicle)" },
{ "rule": "line.status == 'IDLE'" }
],
"effects": [
{ "set": "vehicle.status = 'IN_PRODUCTION'" },
{ "link": "vehicle ASSIGNED_TO line" }
],
"permissions": ["role:PLANT_MANAGER"],
"audit": "auto"
}
4.2 跨系统调用对比
DDD 体系下，三个服务各有一套领域模型，靠领域事件 + 上下文映射协作；每跨一个上下文都要做防腐层翻译。
Ontology 体系下，三个领域共享同一套语义底座，跨系统调用即在同一个 Ontology 内调用 Action——不需要"防腐层"，因为根本没有"腐"可防。
代价对比：DDD 的代价是"跨上下文翻译成本"；Ontology 的代价是"必须先有一个像 Foundry 这样的平台"。前者可以用 Spring + Kafka 起步，后者需要数百万级的平台采购或自建。
5.1 各类业务现象的建模能力
🔗 原文链接: 点击阅读原文
文章评论