用途：在 Directus 中为产品定义数据模型的“事实契约”，明确哪些数据可读可写、关系如何运作，以及系统如何在不破坏既有集成的前提下演进。适合搭建项目 schema 或审查已有模型时使用。
主要能力与原则：按领域（bounded context）而非按页面建模；把关系视为行为，围绕真实查询（列表、详情、筛选）来设计；保持稳定，避免在没有迁移策略时重命名或重构。
Collections：创建时明确用途（读/写）与类型（目录、内容、事务、配置）；命名一致，用复数、避免晦涩缩写；若变更会破坏调用方，按版本化处理。
Fields：选对类型（字符串、数字、布尔、日期时间戳、JSON、枚举）；封闭取值域优先用类型或约束限制；非必要不要用松散 JSON 之类的“万能字段”。验证方面，能在 Directus 内完成的格式与范围校验就放在此层，减少客户端负担；面向用户的提示要清晰，面向日志的信息要技术化。
Relations：一对多用于“父有多个子”且按父查询；多对多用关系本身带语义或需要带属性的连接表的场景；多态仅在合理时使用，否则拆分 Collections。按意图命名（如 trip.driver、trip.passengers），便于代码生成与 DTO 阅读；避免不必要的循环关系。
系统字段与流程：决定并记录时间戳（created、updated，视项目而定）、状态/发布流程（草稿→已发布，若内容需审核）、用户归属（作者字段，若项目使用）。有草稿时，需定义哪些角色能看到什么（草稿仅内部、已发布对公众）。
版本化与 schema 演进：兼容变更先添加可选字段或关系；不兼容变更新建版本化 Collection/列，或迁移并保留回退；把“事实来源”保存在导出的 schema 或迁移目录中（参见 directus-migrations-import-export）。
完成标准：命名与类型反映真实领域；关系支撑真实查询（列表/详情/搜索），无需在客户端临时处理 N+1；草稿/状态规则与角色、策略一致；schema 演进有策略（兼容→版本化→迁移）。
限制：本资料为技能说明，未提供具体安装命令、价格、平台支持或完整代码示例；实际实现需结合项目与 Directus 版本自行确认。