Ontology design: Best practices（本体论设计：最佳实践）

A well-designed Ontology creates a unified, intuitive representation of your organization that enables seamless data integration, cross-functional collaboration, and powerful analytics. This section provides both a quick-reference set of design guidelines and a deeper treatment of the core design principles that underpin them.

Design guidelines

The following guidelines are a practical checklist for Ontology design. Where applicable, each one is grounded in a core design principle, anti-pattern, or structural recommendation.

1. Model reality, not systems: Object types should represent real-world entities, not individual source system or department representations.
2. Design principle: Domain-driven design
3. Curate intentionally: Every property should have clear business or technical value.
4. Structural recommendation: Normalization and derived properties
5. Collaborate across teams: Ontology design should involve stakeholders from multiple departments or teams. Siloed teams are a leading cause of duplication.
6. Design principle: Don't repeat yourself
7. Keep object types focused: Each object type should represent one distinct entity.
8. Design principle: Domain-driven design
9. Choose the right tool: Use action types for human or agentic decisions and pipelines for automated transformations.
10. Anti-pattern: The Golden Hammer
11. Use interfaces for abstraction: When entities share common characteristics, model the abstraction with interfaces rather than creating wide, sparse object types.
12. Design principle: Composition over deep hierarchies
13. Document your decisions: Document object types, properties, and links in Ontology Manager.

Core design principles

These four principles are derived from extensive field experience across government and commercial implementations. They are presented in priority order. In cases of conflict, higher-priority principles take precedence.

Priority	Principle	Core idea
1	Domain-driven design	Model the real world, not the source data.
2	Don't repeat yourself	If you built the same thing three times, refactor.
3	Open for extension, closed for modification	Protect core models. Enable builders to extend them.
4	Composition over deep hierarchies	Favor multiple inheritance via interfaces. Keep things pluggable.

Practical considerations should always factor into any decision. Review the section on pragmatism and tradeoffs for more information.

1. Domain-driven design

The Ontology models the real world, not the source data.

Objects should represent semantically meaningful real-world concepts (such as a Patient, a WorkOrder, or a Vessel) not database tables, API responses, or spreadsheet tabs. Links should represent real relationships ("this patient visited this facility"), not join keys or foreign key artifacts.

When asked to "ontologize a dataset", resist the urge to map columns 1:1 to properties and consider the work complete. The Kitchen Sink anti-pattern produces an Ontology that mirrors source system schema quirks rather than useful semantics. A well-designed Ontology should feel intuitive to use; a user, or an AI agent, should be able to navigate it without friction, because the structure matches how they already think about their domain.

Anti-patterns

• Object types mirror source system tables rather than domain entities
• Properties are mapped 1:1 from source columns without curation
• Names come from source system conventions (dtLastInspMod) rather than business language (lastInspectionDate)
• The object model was designed by looking at the data rather than understanding the domain
• A single source row containing multiple entities is modeled as a single object type

Example

A CSV with columns order_id, customer_name, customer_email, product_sku, and quantity describes at least three real-world entities, not one:

✗ Avoid                                    ✓ Prefer
────────────────────────────────────────   ────────────────────────────────────────
OrderData                                  Order
  - order_id                                 - order_id
  - customer_name                            - quantity
  - customer_email                →          - Links to → Customer, Product
  - product_sku
  - quantity                               Customer
                                             - name
(One object type mirroring the CSV)          - email

                                           Product
                                             - sku

                                           (Three object types modeling the domain)

Impact of anti-patterns

Problem	Impact
Unintuitive model	Users and AI agents cannot navigate the Ontology naturally because the structure does not match how they think about the domain.
Fragile coupling to source	Schema changes in source systems break Ontology consumers because the Ontology mirrors source structure rather than abstracting over it.
Missed relationships	Entities embedded as columns (like customer_name on an order) cannot be linked, searched, or reasoned about independently.
Poor reuse	Object types shaped by one system's schema are difficult for other teams or use cases to adopt.

Best practices

1. Identify real-world entities before looking at source schemas: Work with domain stakeholders to define what concepts matter. A single dataset often describes multiple entities.
2. Separate identity from observation: If a row represents a measurement or event about an entity, the entity and the observation are likely different object types.
3. Name things for humans: API names should be intuitive and self-documenting. Prefer person.children over person.linkedChildPersonObjects. Prefer equipment.lastInspectionDate over equipment.dtLastInspMod.
4. Model the domain, then map the data: Understand the domain, then design the object model, then map source data into that model. Do not attempt to look at the data and replicate its shape.
5. Mark non-semantic types as hidden: When non-semantic types (types that serve a technical purpose rather than modeling real-world domain entities) are necessary for specific workflows, mark them as hidden to keep default views of the Ontology clean. They remain available for builders to leverage when building applications.

2. Don't repeat yourself (rule of three)

If you built the same thing three times, refactor.

Duplicated object types, redundant properties, and copy-pasted workflows are a maintenance burden and a context-management problem, for both humans and AI agents that need to reason about the Ontology. The goal is a single canonical representation for each concept, with a single canonical workflow for each operation on that concept. The rule of three is a practical trigger for applying this principle: one instance is a coincidence, two is a pattern, and three means it is time to refactor.

Anti-patterns

• Multiple object types share the same set of properties and similar links
• The same derived property logic or action logic appears across multiple types
• Different teams have created near-identical object types for slightly different purposes
• Copy-pasted workflows exist with minor variations across types

Example

Three teams have independently created customer-related object types with overlapping schemas:

✗ Avoid                                    ✓ Prefer
────────────────────────────────────────   ────────────────────────────────────────
Sales Customer                             Customer (single canonical type)
  - name                                     - name
  - email                                    - email
  - phone                                    - phone
                                             - salesStatus
Support Customer                   →         - supportTier
  - name                                     - billingAccountId
  - email
  - phone                                 — OR, if shapes are genuinely distinct —

Billing Customer                           Interface: CustomerBase
  - name                                     - name
  - email                                    - email
  - phone                                    - phone

(Three types, three sets of actions,       Implemented by: SalesLead, SupportContact,
 three maintenance burdens)                BillingAccount

Impact of anti-patterns

Problem	Impact
Maintenance burden	Changes must be replicated across every duplicate. Missed updates cause drift between copies.
Ambiguous context	Users and AI agents cannot determine which of several near-identical types is canonical.
Inconsistent behavior	Duplicated action or derived property logic diverges over time, producing conflicting results.
Wasted development effort	Teams re-build the same thing in slightly different forms instead of collaborating on one shared model.

Best practices

1. Audit for duplicates: If multiple object types share a common shape (same properties, similar links, similar actions), evaluate whether they should be a single type with a distinguishing property or should implement a shared interface.
2. Consolidate shared logic: If the same derived property or action logic appears across multiple types, extract it into an interface or shared function.
3. Unify team-specific copies: When different groups have created near-identical object types, unify them into a single canonical representation with appropriate security or filtering.
4. Apply the rule of three: One duplicate can be acceptable. Two is a warning sign. Three means it is time to refactor.

3. Open for extension, closed for modification

Protect core models. Enable builders to extend them.

Once an object type, interface, or workflow is field-tested and in production, its core structure should be stable. Other developers and teams in the organization should be able to build on top of it, adding new object types that implement an interface or new workflows that consume existing objects, without needing to modify the core model.

Anti-patterns

• Frequent breaking changes to established object types that cascade across dependent applications
• New use cases require modifying existing core types rather than extending them
• Teams need to edit shared interfaces or actions to accommodate team-specific needs
• Security changes for one team's extension inadvertently affect other consumers

Example

A core Equipment object type and Inspectable interface are in production. A new team needs to track certification data for some equipment:

✗ Avoid                                    ✓ Prefer
────────────────────────────────────────   ────────────────────────────────────────
Modify the core Equipment type:            Extend without modifying core:

Equipment                                  Equipment (unchanged)
  - serialNumber                             - serialNumber
  - manufacturer                             - manufacturer
  - certificationAuthority   (new)   →       - Links to → Equipment Certification
  - certificationExpiry      (new)
  - certificationStatus      (new)         Equipment Certification (new linked type)
  - lastCertAudit            (new)           - certificationAuthority
                                             - certificationExpiry
(Four new properties, null for all           - certificationStatus
 non-certified equipment, existing           - lastCertificationAudit
 consumers must handle the change)
                                           New interface: Certifiable
                                             - certificationStatus
                                             - certificationExpiry

                                           (Core type untouched, new capability
                                            added via linked type and interface)

Impact of anti-patterns

Problem	Impact
Breaking changes	Modifications to core types can break dependent applications, actions, and workflows across the organization.
Scope creep	Core types accumulate properties and logic for every new use case, trending toward a God Object.
Entangled ownership	Multiple teams modify the same core type, creating merge conflicts and unclear accountability.
Security leakage	Extending a core type without clean boundaries can inadvertently widen data access.

Best practices

1. Identify what is essential: Determine which properties and links are truly fundamental to the entity. Lock those down.
2. Design for extension: When creating core types and interfaces, anticipate that others will build on them. Leave room for linked extension types and new interface implementations.
3. Extend rather than modify: When adding to an existing model, consider if the addition belongs on the core type, or on an extension (a new linked object type, a new interface implementation, or a new property namespace).
4. Enforce security boundaries: Core data models should have well-defined security boundaries so that extending the Ontology does not inadvertently widen access.

4. Composition over deep hierarchies

Favor multiple inheritance via interfaces. Keep things pluggable.

Foundry's Ontology supports multiple inheritance through interfaces, so an entity can compose behavior from multiple focused abstractions instead of a single-inheritance chain.

Anti-patterns

• Deep single-inheritance chains where child types exist solely to combine parent capabilities
• "Combination" types like SchedulableBuilding or InspectableVehicle that merge two unrelated concepts into one type
• Workflows are tightly coupled to specific object types when they could operate on a shared interface
• Adding a new capability to an entity requires restructuring the inheritance chain

Example

An Arena needs to be both a building and a schedulable resource:

✗ Avoid                                    ✓ Prefer
────────────────────────────────────────   ────────────────────────────────────────
Deep single-inheritance:                   Composed interfaces:

Asset                                      Interface: Building
  └── PhysicalAsset                          - address
        └── Building                         - squareFootage
              └── SchedulableBuilding
                    └── Arena              Interface: SchedulableResource
                                             - schedulingCalendar
(Every new combination of capabilities       - bookingPolicy
 requires a new intermediate type.
 A SchedulableWarehouse would need         Arena implements both:
 yet another branch.)                        Building + SchedulableResource
                                             - arenaName
                                             - seatingCapacity

                                           (Adding SchedulableWarehouse only
                                            requires implementing the same two
                                            interfaces — no new hierarchy needed.)

Impact of anti-patterns

Problem	Impact
Combinatorial explosion	Every new combination of capabilities requires a new intermediate type in the hierarchy.
Brittle hierarchies	Changes to a parent type cascade unpredictably through all descendants.
Limited reuse	Workflows built on a specific type deep in the chain cannot be reused for other types that share the same capability.
Semantic distortion	Contrived parent types (like SchedulableBuilding) do not represent real-world concepts, violating the domain-driven design principle.

Best practices

1. Design interfaces around capabilities or roles: Use focused interfaces like Inspectable, Schedulable, Billable, or Depreciable that capture a specific behavior or property set.
2. Use taxonomic interfaces for aggregation: Taxonomic identity interfaces (for example, MilitaryAsset implemented by Aircraft, Vessel, GroundVehicle) are particularly useful for drilldown investigations or similar aggregation workflows.
3. Target interfaces in workflows: When building actions, functions, and applications, target interfaces where possible. A workflow built on the SchedulableResource interface works for arenas, conference rooms, and vehicles without modification.
4. Compose rather than inherit: When an entity needs multiple capabilities, implement multiple interfaces rather than inserting it into a deep single-inheritance chain.

Pragmatism and tradeoffs

These principles are guides, not laws.

Real-world constraints, including deadlines, legacy systems, partial platform support, and user skill levels, mean that the ideal Ontology design is not always immediately achievable. Use the following guidelines to navigate tradeoffs:

Guideline	Detail
Steer toward good design without being a roadblock	If something needs to be working within a tight deadline, build something reasonable now with a clear path to improvement.
Name the tradeoffs explicitly	When recommending a shortcut, explain what is being traded away and when it might matter. For example, a denormalization could work fine at your current scale, but if you grow past 10k objects, you may want to revisit.
Prefer incremental improvement over big-bang refactors	A slightly imperfect Ontology that is in use and generating value is better than a theoretically perfect one that is still being designed.
Defend the critical invariants	Naming quality, semantic clarity, and security design are hard to fix later. Cut corners on implementation details, not on these.

The Ontology is the software that powers your organization. Treat it with the same care you would give to a production codebase, but prioritize business value over perfection.

---

中文翻译

本体论设计：最佳实践

一个设计良好的本体论(Ontology)能够为您的组织创建统一、直观的表示，实现无缝的数据集成、跨职能协作和强大的分析能力。本节既提供了一套快速参考的设计指南，也深入探讨了支撑这些指南的核心设计原则。

设计指南

以下指南是本体论设计的实用检查清单。在适用的情况下，每条指南都基于核心设计原则、反模式或结构建议。

1. 建模现实，而非系统： 对象类型(Object types)应表示现实世界的实体，而非单个源系统或部门的表示。
2. 设计原则： 领域驱动设计
3. 有目的地进行策划： 每个属性(Property)都应有明确的业务或技术价值。
4. 结构建议： 规范化和派生属性
5. 跨团队协作： 本体论设计应涉及多个部门或团队的利益相关者。孤立的团队是重复的主要原因。
6. 设计原则： 不要重复自己
7. 保持对象类型聚焦： 每个对象类型应表示一个独立的实体。
8. 设计原则： 领域驱动设计
9. 选择合适的工具： 使用操作类型(Action types)处理人工或智能体决策，使用管道(Pipelines)处理自动化转换。
10. 反模式： 金锤子
11. 使用接口(Interfaces)进行抽象： 当实体共享共同特征时，使用接口对抽象进行建模，而不是创建宽泛、稀疏的对象类型。
12. 设计原则： 组合优于深层继承
13. 记录您的决策： 在Ontology Manager中记录对象类型、属性和链接。

核心设计原则

这四项原则源自政府和商业实施中的广泛现场经验。它们按优先级顺序排列。在冲突情况下，优先级更高的原则优先。

优先级	原则	核心理念
1	领域驱动设计	对现实世界建模，而非源数据。
2	不要重复自己	如果同一件事做了三次，就重构。
3	对扩展开放，对修改关闭	保护核心模型。让构建者能够扩展它们。
4	组合优于深层继承	优先通过接口实现多重继承。保持可插拔性。

实际考量应始终纳入任何决策。请参阅实用主义与权衡部分了解更多信息。

1. 领域驱动设计

本体论对现实世界建模，而非源数据。

对象应表示语义上有意义的现实世界概念（例如患者(Patient)、工单(WorkOrder)或船舶(Vessel)），而不是数据库表、API响应或电子表格标签。链接应表示真实的关系（"该患者访问了该设施"），而不是连接键或外键产物。

当被要求"将数据集本体论化"时，要抵制将列1:1映射到属性并认为工作完成的冲动。厨房水槽反模式会产生一个反映源系统模式怪癖而非有用语义的本体论。一个设计良好的本体论应该使用起来直观；用户或AI智能体应该能够无摩擦地导航，因为其结构匹配他们对该领域的已有认知。

反模式

• 对象类型反映源系统表而非领域实体
• 属性未经策划就从源列1:1映射
• 名称来自源系统约定（dtLastInspMod）而非业务语言（lastInspectionDate）
• 对象模型是通过查看数据而非理解领域来设计的
• 包含多个实体的单个源行被建模为单个对象类型

示例

一个包含列order_id、customer_name、customer_email、product_sku和quantity的CSV描述了至少三个现实世界实体，而非一个：

✗ 避免                                    ✓ 推荐
────────────────────────────────────────   ────────────────────────────────────────
OrderData                                  Order
  - order_id                                 - order_id
  - customer_name                            - quantity
  - customer_email                →          - 链接到 → Customer, Product
  - product_sku
  - quantity                               Customer
                                             - name
(一个反映CSV的对象类型)                        - email

                                           Product
                                             - sku

                                           (三个建模领域的对象类型)

反模式的影响

问题	影响
不直观的模型	用户和AI智能体无法自然地导航本体论，因为结构不匹配他们对领域的思考方式。
与源的脆弱耦合	源系统中的模式变更会破坏本体论消费者，因为本体论反映源结构而非对其进行抽象。
遗漏的关系	嵌入为列的实体（如订单上的customer_name）无法被独立链接、搜索或推理。
复用性差	由某个系统模式塑造的对象类型难以被其他团队或用例采用。

最佳实践

1. 在查看源模式之前识别现实世界实体： 与领域利益相关者合作，定义哪些概念重要。单个数据集通常描述多个实体。
2. 区分身份与观察： 如果一行表示关于某个实体的测量或事件，那么该实体和观察结果很可能是不同的对象类型。
3. 为人命名： API名称应直观且自文档化。优先使用person.children而非person.linkedChildPersonObjects。优先使用equipment.lastInspectionDate而非equipment.dtLastInspMod。
4. 先建模领域，再映射数据： 理解领域，然后设计对象模型，再将源数据映射到该模型中。不要试图查看数据并复制其形状。
5. 将非语义类型标记为隐藏： 当特定工作流需要非语义类型（服务于技术目的而非建模现实世界领域实体的类型）时，将其标记为隐藏以保持本体论的默认视图整洁。它们仍然可供构建者在构建应用程序时使用。

2. 不要重复自己（三的原则）

如果同一件事做了三次，就重构。

重复的对象类型、冗余的属性和复制粘贴的工作流是维护负担和上下文管理问题，对于需要推理本体论的人类和AI智能体都是如此。目标是每个概念有一个规范的表示，每个对该概念的操作有一个规范的工作流。三的原则是应用此原则的实用触发器：一次是巧合，两次是模式，三次就是时候重构了。

反模式

• 多个对象类型共享相同的属性集和相似的链接
• 相同的派生属性逻辑或操作逻辑出现在多个类型中
• 不同团队为略有不同的目的创建了几乎相同的对象类型
• 跨类型存在具有微小差异的复制粘贴工作流

示例

三个团队独立创建了具有重叠模式的客户相关对象类型：

✗ 避免                                    ✓ 推荐
────────────────────────────────────────   ────────────────────────────────────────
Sales Customer                             Customer (单一规范类型)
  - name                                     - name
  - email                                    - email
  - phone                                    - phone
                                             - salesStatus
Support Customer                   →         - supportTier
  - name                                     - billingAccountId
  - email
  - phone                                 — 或者，如果形状确实不同 —

Billing Customer                           Interface: CustomerBase
  - name                                     - name
  - email                                    - email
  - phone                                    - phone

(三种类型，三套操作，                      由以下实现: SalesLead, SupportContact,
 三个维护负担)                              BillingAccount

反模式的影响

问题	影响
维护负担	变更必须复制到每个副本。遗漏的更新会导致副本间出现偏差。
上下文模糊	用户和AI智能体无法确定几个几乎相同的类型中哪个是规范的。
行为不一致	重复的操作或派生属性逻辑随时间推移产生分歧，导致冲突的结果。
开发工作浪费	团队以略有不同的形式重新构建相同的东西，而不是在一个共享模型上协作。

最佳实践

1. 审计重复项： 如果多个对象类型共享共同形状（相同属性、相似链接、相似操作），评估它们是否应成为具有区分属性的单一类型，或者应实现共享接口。
2. 整合共享逻辑： 如果相同的派生属性或操作逻辑出现在多个类型中，将其提取到接口或共享函数中。
3. 统一特定团队的副本： 当不同组创建了几乎相同的对象类型时，将它们统一为具有适当安全性或过滤的单一规范表示。
4. 应用三的原则： 一个副本可以接受。两个是警告信号。三个就是时候重构了。

3. 对扩展开放，对修改关闭

保护核心模型。让构建者能够扩展它们。

一旦对象类型、接口或工作流经过现场测试并投入生产，其核心结构应保持稳定。组织中的其他开发者和团队应能够在其基础上构建，添加实现接口的新对象类型或消费现有对象的新工作流，而无需修改核心模型。

反模式

• 频繁对已建立的对象类型进行破坏性变更，级联影响依赖的应用程序
• 新用例需要修改现有核心类型而非扩展它们
• 团队需要编辑共享接口或操作以适应特定团队的需求
• 某个团队扩展的安全变更无意中影响其他消费者

示例

一个核心Equipment对象类型和Inspectable接口已投入生产。一个新团队需要跟踪某些设备的认证数据：

✗ 避免                                    ✓ 推荐
────────────────────────────────────────   ────────────────────────────────────────
修改核心Equipment类型：                     在不修改核心的情况下扩展：

Equipment                                  Equipment (不变)
  - serialNumber                             - serialNumber
  - manufacturer                             - manufacturer
  - certificationAuthority   (新增)   →       - 链接到 → Equipment Certification
  - certificationExpiry      (新增)
  - certificationStatus      (新增)         Equipment Certification (新增链接类型)
  - lastCertAudit            (新增)           - certificationAuthority
                                             - certificationExpiry
(四个新属性，所有非认证设备为null，            - certificationStatus
 现有消费者必须处理此变更)                     - lastCertificationAudit

                                           新接口: Certifiable
                                             - certificationStatus
                                             - certificationExpiry

                                           (核心类型未触及，通过链接类型和接口
                                            添加了新能力)

反模式的影响

问题	影响
破坏性变更	对核心类型的修改可能破坏整个组织的依赖应用程序、操作和工作流。
范围蔓延	核心类型为每个新用例积累属性和逻辑，趋向于上帝对象。
所有权纠缠	多个团队修改同一核心类型，造成合并冲突和职责不清。
安全泄露	在没有清晰边界的情况下扩展核心类型可能无意中扩大数据访问范围。

最佳实践

1. 识别什么是本质的： 确定哪些属性和链接对实体真正基础。锁定它们。
2. 为扩展而设计： 在创建核心类型和接口时，预见到其他人会在其基础上构建。为链接扩展类型和新接口实现留出空间。
3. 扩展而非修改： 在向现有模型添加内容时，考虑该添加属于核心类型，还是属于扩展（新的链接对象类型、新的接口实现或新的属性命名空间）。
4. 强制执行安全边界： 核心数据模型应有明确定义的安全边界，以便扩展本体论不会无意中扩大访问范围。

4. 组合优于深层继承

优先通过接口实现多重继承。保持可插拔性。

Foundry的本体论通过接口支持多重继承，因此实体可以从多个聚焦的抽象中组合行为，而不是使用单一继承链。

反模式

• 深层单一继承链，其中子类型的存在仅仅是为了组合父级能力
• "组合"类型如SchedulableBuilding或InspectableVehicle，将两个不相关的概念合并为一个类型
• 工作流与特定对象类型紧密耦合，而它们本可以在共享接口上操作
• 向实体添加新能力需要重构继承链

示例

一个Arena需要同时是建筑物和可调度资源：

✗ 避免                                    ✓ 推荐
────────────────────────────────────────   ────────────────────────────────────────
深层单一继承：                               组合接口：

Asset                                      Interface: Building
  └── PhysicalAsset                          - address
        └── Building                         - squareFootage
              └── SchedulableBuilding
                    └── Arena              Interface: SchedulableResource
                                             - schedulingCalendar
(每种新的能力组合都需要一个新的中间类型。       - bookingPolicy
 SchedulableWarehouse需要另一个分支。)      
                                           Arena 实现两者：
                                             Building + SchedulableResource
                                             - arenaName
                                             - seatingCapacity

                                           (添加SchedulableWarehouse只需要
                                            实现相同的两个接口——无需新层次结构。)

反模式的影响

问题	影响
组合爆炸	每种新的能力组合都需要层次结构中的新中间类型。
脆弱的层次结构	对父类型的更改不可预测地级联到所有后代。
复用性有限	构建在深层链中特定类型上的工作流无法为共享相同能力的其他类型复用。
语义扭曲	人为构造的父类型（如SchedulableBuilding）不表示现实世界概念，违反了领域驱动设计原则。

最佳实践

1. 围绕能力或角色设计接口： 使用聚焦的接口如Inspectable、Schedulable、Billable或Depreciable，捕获特定的行为或属性集。
2. 使用分类接口进行聚合： 分类身份接口（例如，由Aircraft、Vessel、GroundVehicle实现的MilitaryAsset）对于钻取调查或类似的聚合工作流特别有用。
3. 在工作流中定位接口： 在构建操作、函数和应用程序时，尽可能定位接口。构建在SchedulableResource接口上的工作流无需修改即可适用于竞技场、会议室和车辆。
4. 组合而非继承： 当实体需要多种能力时，实现多个接口，而不是将其插入深层单一继承链。

实用主义与权衡

这些原则是指导方针，而非法律。

现实世界的约束，包括截止日期、遗留系统、部分平台支持和用户技能水平，意味着理想的本体论设计并非总是立即可实现的。使用以下指南来导航权衡：

指南	详情
朝着良好设计前进，但不要成为障碍	如果某件事需要在紧迫的截止日期前完成，现在构建一个合理的东西，并明确改进路径。
明确命名权衡	在推荐捷径时，解释正在牺牲什么以及何时可能重要。例如，反规范化在当前规模下可能工作良好，但如果增长超过1万个对象，您可能需要重新审视。
优先增量改进而非大爆炸式重构	一个略有缺陷但正在使用并产生价值的本体论，优于一个理论上完美但仍在设计中的本体论。
捍卫关键不变量	命名质量、语义清晰度和安全设计后期难以修复。在实现细节上走捷径，而不是在这些方面。

本体论是为您的组织提供动力的软件。像对待生产代码库一样对待它，但优先考虑业务价值而非完美。