ERP本体建模的性能问题，往往不在于业务概念定义得太完整，而在于把所有关系查询、规则判断和状态推导都放进实时交易链路。语义统一不等于存储统一，更不等于每笔交易都要遍历完整本体。平衡的关键，是统一业务含义，同时按场景限制运行时的计算范围。
统一定义，保留业务边界
以“客户”为例，最终用户、开票对象和收货方不宜被压缩成一个无差别的对象。更合理的做法是明确各自角色、标识及关联关系，让不同模块能够准确映射，而不是强行合并字段与数据。
本体应优先覆盖会影响跨模块判断的实体、状态和约束。仅服务于局部操作的细节，可以留在业务模块内，通过明确映射接入。这样既能避免语义冲突，也能减少不必要的关系展开与维护负担。
把计算放在合适的位置
订单异常处理需要库存、在途订单和替代物料信息，但不意味着每次请求都要获取整个供应链的关联数据。应按任务限定查询对象、关联范围和返回内容；只有确实影响当前判断的信息，才进入实时上下文。
稳定的关系映射、重复使用的派生结果，可以考虑预先计算或缓存，但必须同时设计更新与失效机制。库存是否充足、单据状态是否允许操作等决定交易合法性的条件，则应在执行时由ERP重新校验，不能用缓存结果替代。建议生成可以容忍一定延迟，交易提交不能牺牲正确性。
本体负责表达业务含义和规则关联，ERP现有规则负责执行交易校验，应避免两边独立维护同一套判断逻辑。否则不仅增加计算开销，还可能出现语义一致、执行结果却不一致的问题。
评估方案时，应围绕具体场景同时检查语义覆盖、查询响应、交易负载和数据更新延迟。先在单一业务域验证：哪些关系必须实时访问，哪些结果可以复用，哪些校验必须保留在提交环节。性能优化应减少无效计算，而不是删掉决定业务正确性的约束。