用途：在建模存储、API 或实现之前先建模业务语言。该技能把已评审的需求文档（requirements-doc）转化为稳定的业务语言契约，减少歧义，避免后续阶段过早锁定 schema、API 或实现决策。它属于领域层，不是数据库设计、API 设计或任务规划。
主要能力与流程：
- 识别核心实体：抽取代表真实业务概念的名词与动词短语（如 campaign、reviewer assignment、evidence package、policy exception），优先使用问题空间概念，而非 table、queue、endpoint、job 等解决方案空间占位词。
- 定义关系：映射实体间关系，明确一对一/一对多/多对多、可选与必选、真源与派生视图，以及遗留系统共存时的过渡性关系。
- 建立统一语言（Ubiquitous Language）：创建带精确定义的术语表，解决同义词问题，例如 Customer 与 User 是否同义、Order 在点击购买时还是支付成功时创建。遗留或租户特定术语单独记录，避免其悄然主导新模型。
- 识别限界上下文：仅在需求证明存在真实语言或职责拆分时引入，例如 Order Context、Payment Context、User Context。不要对只需一个连贯领域模型的简单切片强行套用 DDD 词汇。
- 与领域专家验证：用真实场景走查模型，包括正常路径、错误或异常路径、遗留或兼容边界。
输出：domain-model，包含共享术语表、核心实体、关系、权威边界及有依据的限界上下文。
质量门：核心实体与关系有可视化记录（如 ER 图）；统一语言术语表获团队认可；系统足够复杂时识别出限界上下文；模型经至少 3 个真实业务场景验证。
反模式：数据库优先建模（应先设计领域模型再推导数据库 schema）；条件反射式划分限界上下文；为查询性能过早优化；让遗留术语悄然成为未来规范模型。
相关技能：requirements-engineering 提供需求；data-modeling 将领域模型转为数据 schema；api-design 使用领域语言设计 API 资源。安装通过 npx skills add/update 支持，发行面为 skills/.curated，作者源为 skills/01-specification/domain-modeling/SKILL.md，打包稳定性与能力就绪度均为 beta。