用途
Domain Modeling 用于在设计和讨论过程中主动构建并打磨项目的领域模型。它针对的是那些正在改变模型、而不仅仅是消费模型的场景。该技能适用于：讨论代码库术语、编写或编辑 GLOSSARY.md，以及记录或编辑 ADR（架构决策记录）。
文件结构
大多数仓库只有一个上下文，其结构通常为根目录下放置 GLOSSARY.md，文档目录中放置 docs/adr/，源码放在 src/。
如果根目录存在 GLOSSARY-MAP.md，则说明仓库有多个上下文。该映射文件指向每个上下文所在的位置。例如系统级决策放在 docs/adr/，而各上下文的词汇表和决策分别位于 src/ordering/ 和 src/billing/ 下。
文件按需创建：只有当你确实有内容要写时才创建。如果不存在 GLOSSARY.md，则在第一个术语确定时创建。如果不存在 docs/adr/，则在需要第一个 ADR 时创建。
会话期间的做法
对照词汇表提出质疑：当用户使用的术语与 GLOSSARY.md 中已有的语言冲突时，立即指出。“你的词汇表把 'cancellation' 定义为 X，但你似乎指的是 Y。到底是哪一个？”
精炼模糊语言：当用户使用含糊或负载过重的术语时，提出一个精确的规范术语。“你说的是 'account'：你是指 Customer 还是 User？这是两个不同的东西。”
讨论具体场景：当讨论领域关系时，用具体场景进行压力测试。构想能探测边界情况的场景，迫使用户明确概念之间的边界。
与代码交叉对照：当用户描述某事物的运作方式时，检查代码是否一致。如果发现矛盾，就把它摆出来：“你的代码取消的是整个 Order，但你刚说部分取消是可能的。哪个才是对的？”
就地更新 GLOSSARY.md：当一个术语确定时，当场更新 GLOSSARY.md。不要攒着批量处理，要随发生随记录。使用 GLOSSARY-FORMAT.md 中的格式。GLOSSARY.md 应完全不包含实现细节，它不是规格说明、草稿本或实现决策的存放处，它只是词汇表。
谨慎提议 ADR：只有在以下三个条件全部满足时才提议创建 ADR：难以逆转（以后改变主意的成本很大）、缺乏上下文会令人惊讶（未来的读者会想“他们为什么这样做？”）、是真实权衡的结果（确实存在多种选择，你出于特定原因选择了一种）。如果缺少任何一条，就跳过 ADR。使用 ADR-FORMAT.md 中的格式。
适用场景
适用于软件项目的设计讨论与文档维护阶段，尤其是需要统一团队术语、记录重要架构决策、保持代码与领域概念一致的情形。
限制
资料中未提供该技能的安装命令、具体代码实现、支持平台、收费方式或使用效果等信息。