domain-modeling
使用主动词汇构建精确的领域模型
当团队使用不一致的术语或忘记决策背后的原因时,软件项目就会受到影响。本技能通过质疑术语、构造边界场景,并将决策记录在 CONTEXT.md 和 ADR 中,帮助你主动构建和打磨领域模型。
下载技能 ZIP
在 Claude 中上传
前往 设置 → 功能 → 技能 → 上传技能
开启并开始使用
测试它
正在使用“domain-modeling”。 用户说:"当客户取消订单时,我们需要退款。"
预期结果:
回复:"你的词汇表将 'cancellation' 定义为在履行之前结束订单,但退款是计费概念。你是要取消订单并在 Billing 中触发退款事件,还是取消本身就是计费操作?让我们明确哪个上下文拥有这个职责。"
正在使用“domain-modeling”。 用户决定在事件溯源系统中对写模型使用 PostgreSQL。
预期结果:
回复:"这符合 ADR 的条件——难以逆转(数据库选择)、脱离上下文会令人意外(为什么选择 Postgres 而不是事件存储?)、存在真正的权衡(考虑了替代方案)。现在创建 ADR-0003-postgres-for-write-model.md。"
安全审计
安全This skill contains only markdown documentation describing domain modeling practices, CONTEXT.md format, and ADR format. Static analysis flagged false positives: backtick matches are markdown inline code formatting, not shell execution; cryptographic matches are coincidental word fragments in documentation; system reconnaissance flags refer to file path references in examples, not actual filesystem access. No executable code, scripts, network calls, or malicious patterns were found.
风险因素
📁 文件系统访问 (3)
质量评分
你能构建什么
开始新的领域模型
在开始新项目时使用,以在编写代码之前建立初始词汇表并记录关键的架构选择。
解决术语冲突
在团队讨论中,当不同成员对同一概念使用不同词汇并需要明确时使用。
记录架构决策
在做出重大技术选择(例如数据库选型或集成模式)时使用,以便未来的开发人员能够理解。
试试这些提示
帮我构建这个项目的领域模型。首先读取 CONTEXT.md(如果存在),然后在我们讨论设计时主动质疑我使用的任何术语。
我在刚才的讨论中使用了 "account" 这个术语。请检查 CONTEXT.md 并告诉我这是否与我们定义的词汇冲突,然后提出我们应该使用的精确术语。
我们刚刚定义了 Order 和 Invoice 之间的关系。请构造 3 个边界场景来探查这两个概念之间的边界,迫使我们更加精确。
我们刚刚决定在写模型中使用事件溯源。请检查这是否满足 ADR 的三个标准(难以逆转、脱离上下文会令人意外、存在真正的权衡)。如果满足,请使用 ADR-FORMAT.md 中的格式创建 ADR。
最佳实践
- 按需创建 CONTEXT.md 和 ADR——只有在有有意义的内容需要记录时才创建
- 立即质疑每个模糊的术语,而不是让混乱累积
- 将 CONTEXT.md 定义保持在一两句话内,聚焦于术语本身是什么
- 仅为难以逆转、脱离上下文会令人意外或涉及真正权衡的决策编写 ADR
避免
- 将 CONTEXT.md 视为规范或实现细节的草稿本
- 为没有真正替代方案的明显决策编写 ADR
- 将通用编程概念(超时、错误类型)添加到词汇表中
- 批量更新术语,而不是在解决时即时记录