{title="📊 页面导航"]

适用角色与上手难度

角色推荐度上手难度
🛠️ 开发★★★★★★★☆☆☆
🧪 测试★★★★☆★★☆☆☆
📦 产品★★★★☆★★★☆☆

🎯 学习产出: 掌握领域建模的主动纪律,能维护干净的领域词汇表和 ADR

🚀 AI 能力提升: 领域理解、术语管理

domain-modeling

预计阅读时间: 4 分钟

领域建模。主动构建和打磨项目的领域模型:挑战术语、发明边界场景、在决策结晶的当下写下词汇表和决策。

这只是"主动"纪律——挑战术语、发明边界场景、结晶当下就写。(单纯"读 CONTEXT.md 找词汇"不是这个技能——那是任何技能都能做的一行习惯。本技能用于改变模型,不只是消费它。)

概述

它维护两类文件:CONTEXT.md(领域词汇表)和 docs/adr/(难逆转决策记录)。懒创建:有东西要写才建文件——首个术语解决时建 CONTEXT.md,首个 ADR 需要时建 docs/adr/

日常使用

> 我们说的"account"到底指什么?
> 帮我梳理一下订单系统的领域术语
> 这个决策要不要记成 ADR?

实战:五种动作

  1. 对照词汇表挑战:用户用词与 CONTEXT.md 冲突时立刻指出——"你的词汇表定义 'cancellation' 为 X,但你似乎指的是 Y,到底是哪个?"
  2. 精化模糊语言:过载词提出规范术语——"你说 'account':指 Customer 还是 User?它们是不同的东西"
  3. 讨论具体场景:领域关系用具体场景压力测试,发明探测边界情况的场景,逼用户精确化概念边界
  4. 与代码交叉验证:用户描述和代码矛盾时指出——"你的代码取消整个 Order,但你刚说支持部分取消,哪个对?"
  5. 就地更新 CONTEXT.md:术语解决就当场更新,不批量积压,用 [CONTEXT-FORMAT.md] 格式。CONTEXT.md 完全不含实现细节——不是规格、不是草稿、不是实现决策仓库,只是词汇表

ADR 要克制

只有三个条件同时为真才提议写 ADR:

  1. 难逆转:以后改主意成本可观
  2. 无上下文会困惑:未来读者会问"为什么这样做?"
  3. 真实取舍的结果:有真正的替代方案,你为具体原因选了一个

缺任何一个就跳过。用 [ADR-FORMAT.md] 格式。

与其它技能的关系

  • 底层词汇层/grill-with-docs 驱动的主动纪律,保持 CONTEXT.md 干净
  • 其它消费者tddtriageto-specimprove-codebase-architecture 都读领域词汇表
  • 多上下文:仓库有 CONTEXT-MAP.md 就是多上下文(根 + 各包的 CONTEXT.mddocs/adr/