避开这 8 个本体设计反模式
建模时最容易踩的坑，往往不是语法错，而是"看似合理、后患无穷"的结构选择。这一篇逐个拆解官方列出的 8 个反模式（anti-pattern），并带你做病例诊断。
https://www.palantir.com/docs/foundry/ontology/ontology-anti-patterns/
原始标题：Ontology anti-patterns
一句话速览
避开这 8 个本体设计反模式：建模时最容易踩的坑，往往不是语法错，而是"看似合理、后患无穷"的结构选择。这一篇逐个拆解官方列出的 8 个反模式（anti-pattern），并带你做病例诊断。
什么是反模式（anti-pattern）
它能跑、能存，但会把你拖进长期维护泥潭。
反模式（anti-pattern）指一种"表面上解决了一个问题、实际上带来更大麻烦"的常见做法。在本体设计里，它通常不是一个会报错的硬错误，而是一个结构性选型错误：建模者用看似合理的捷径，换来了碎片化、难维护、难扩展的本体。
官方文档明确列出了 8 个反模式，覆盖三类问题：实体怎么分（System Silos、Department Silos、God Object、Time Machine）、属性与名字怎么取（Kitchen Sink、Misnomer）、工具与动作怎么用（Golden Hammer、Action Sprawl）。
实体建模反模式（一）：怎么切分现实
这 4 个反模式都出在"一个实体该不该被拆/被合并"上。
The System Silos
系统孤岛 · 按来源系统拆同一个实体病症
基于数据来源系统（而非实体本身）为同一个现实世界实体创建不同的对象类型。例如 HR 系统、门禁系统、项目管理工具里都有"员工"，于是分别建了 HR System Employee、Badge System Employee、Project Management Employee。
危害
现实视图碎片化、动作/链接/应用要重复建多份、同一实体信息互相冲突、业务逻辑改动要在所有类型里重做。
处方
创建代表现实实体的单一对象类型，用数据管道（pipelines）把多源系统合并到统一后备数据集；用主键（如员工 ID）跨系统唯一标识，并定义冲突值的优先规则（如 HR 对职位名有权威性）。
The Department Silos
部门孤岛 · 各部门各建一份病症
不同部门为同一对象类型创建自己的版本，让本体映射了组织结构而非业务现实。例如销售建 Sales Customer、支持建 Support Customer、财务建 Billing Customer、营销建 Marketing Contact。
危害
没有单一真相源、跨职能工作流做不了、重复开发、治理噩梦（一个类型里的修复不会传播到其他类型）。
处方
创建服务多部门的共享对象类型，需要时用属性和链接捕获部门特定信息（如 Customer → Support Ticket）；用受限视图控制属性可见范围。
The God Object
上帝对象 · 一个类型装下所有实体病症
单一对象类型被过度加载，代表多个不同的现实实体。例如一个 Asset 想装下卡车、软件许可证、房产、金融工具，甚至"员工作为人力资产"，结果 150+ 属性，大多数为 null。
危害
语义混淆、稀疏数据（大量 null）、无法强制业务规则、搜索结果混杂、动作类型需要大量条件逻辑。
处方
为不同实体创建不同的对象类型；当实体确实共享特征时，用接口（interfaces）建模共享属性与行为。
The Time Machine
时光机 · 把历史版本建成对象病症
把实体的历史版本建模成独立的对象或对象类型，而不是用时间序列/快照/版本策略。例如同对象类型里放 Contract v1/v2/v3，甚至每年一个 Contract 2023/2024/2025 类型。
危害
对象数量爆炸、当前状态模糊（哪个是权威？）、链接到底链哪版含糊、跨时段报告要去重。
处方
每个实体用单一对象反映当前状态；历史变更存到单独的链接对象类型（如 Contract Amendment），或启用编辑历史、用时间序列属性。
属性与命名反模式（二）：噪声与歧义
这 2 个反模式让本体"看得到、读不懂"。
The Kitchen Sink
洗碗池 · 把无关列全倒进来病症
对象类型包含了来自外部系统、在本体语境中毫无业务关联的不必要列（"everything but the kitchen sink"）。例如从 CRM 建 Customer 时把 _crm_extracted_at、_crm_sequence、last_etl_update_timestamp 等技术产物也暴露成属性。
危害
用户困惑、性能下降（索引变大、搜索变慢）、重要业务属性被技术元数据淹没。
处方
有意地策划属性：只保留业务含义清晰、对工作流有用的列（业务标识、可读属性、业务日期、用于筛选/动作的状态）；ETL 元数据留在后备数据集，不暴露为属性。
The Misnomer
名不副实 · 模糊误导的命名病症
对对象类型、属性、链接类型使用模糊、通用或误导性的名字。例如对象类型叫 Item，属性叫 value、type、date，链接叫 Related Item——没人知道到底指什么。
危害
用户误解、学习曲线陡、文档变成必需且易过时、跨团队各解释各的。
处方
用具体、自解释的名字：模糊属性加限定（monetaryValue）、链接按关系命名（Supervisor）、建立命名规范并加描述。
工具与动作反模式（三）：用错锤子
这 2 个反模式出在"能力选错、动作切太碎"。
The Golden Hammer
黄金锤 · 一把锤子敲所有钉子病症
过度依赖单一工具解决所有问题。俗话说"If all you have is a hammer, everything looks like a nail"（手里只有锤子，看什么都像钉子）。例如用动作类型算本可管道预聚合的指标、用管道做本该事件驱动的自动化、用函数实现本可 concat 的简单派生。
危害
触及工具上限、不必要的复杂度、把本可自动化的步骤推给用户、性能差、调试难。
处方
按用例选工具：批量/流处理用 pipelines；人类决策用 action types；事件驱动反应用 automations；跨多对象的复杂实时逻辑用 functions；循环编排用 schedules。用 automations 填补"变了 → 该发生什么"之间的空白，无需用户点按钮。
The Action Sprawl
动作蔓延 · 一堆单属性动作病症
创建大量范围狭窄、各改一个属性的动作类型，而不是设计有意义业务操作的 cohesive 动作。例如 Update Employee First Name、Update Employee Email……二三十个单属性动作。
危害
用户面对冗长动作列表、一次业务更新要多次提交、动作不映射真实流程、审计轨迹碎片化。
处方
围绕业务操作设计动作：把相关改动打包成有意义工作流（如 Transfer Employee），用动作参数容纳可选字段，以业务操作命名并加规则校验。
怎么识别反模式：常见症状信号
建模中一旦看到这些信号，立刻警觉。
- God Object 信号：大量属性频繁为 null；属性含义随另一个属性的值而变；你忍不住问"这到底是个什么对象？"；业务规则需要大量基于"类型"的条件逻辑。
- System / Department Silos 信号：同一概念在本体里出现多个版本；改一处逻辑要在多处重复；跨团队对"客户/员工"说法不一。
- Kitchen Sink 信号：属性里混着
_etl_*、_received_at之类技术时间戳；用户问"这列是干嘛的？"。 - Misnomer 信号：
value、type、date等无限定名满天飞；不同团队对同名解释不同。 - Action Sprawl 信号：单对象类型动作超 10 个；动作名形如
Set [Property]；用户抱怨步骤太多。 - Golden Hammer 信号：什么都用动作/管道/函数一种工具；本可预计算却实时算。
- Time Machine 信号：对象类型里含
version/isCurrent；对象数随"变更次数"而非"实体数"增长。
病例诊断室：这段建模犯了哪个反模式？
读病例，点"点我诊断 →"翻出病名与处方。
Employee，而是建了 HR System Employee、Badge System Employee、Project Management Employee 三个对象类型。Asset 对象类型想代表"任何有价值的东西"，装进了卡车、软件许可证、房产、金融工具甚至员工，150+ 属性，大多数对任何给定对象都是 null。Customer 时，把 _crm_extracted_at、_crm_sequence、last_etl_update_timestamp 等技术产物也暴露成了属性。Calculate Regional Sales Totals 写回对象，而不是用管道预计算。Employee 建了 Update Employee First Name、Update Employee Email、Update Employee Department 等二十多个动作，每次换部门要连续提交好几个。Contract v1/v2/v3 作为独立对象，每年还另开 Contract 2023/2024/2025 对象类型。一页带走
延伸阅读 · 相关页面
按主题横向跳转，不必顺着目录一篇篇读。
常见问题速答 · FAQ
关于「避开这 8 个本体设计反模式」，读者最常问的几个问题。