domain-modeling

领域建模

将构建、质疑和维护项目的领域模型作为一项持续实践。不要只是阅读 CONTEXT.md；在做决策时，用它来完善术语。

文件

• CONTEXT.md：仅收录已确定领域术语的根术语表。
• CONTEXT-MAP.md：可选的限界上下文映射。若存在，请据此选择适用的上下文术语表或术语。
• docs/adr/：持久化的架构决策记录。

按需创建文件。不要仅仅因为启用了此技能，就创建 CONTEXT.md、CONTEXT-MAP.md 或 docs/adr/。仅在有值得保留的已确定内容时，才创建或更新这些文件。

核心规则

• 将语言视为设计的一部分。质疑含糊的词语、多义术语，以及与现有用法冲突的术语。
• 在命名抽象概念前，先讨论具体场景。优先使用真实工作流、用户、数据和代码路径中的示例。
• 尽可能交叉参照代码库。如果某个术语已在代码中出现，请先检查相关文件，再请用户定义。
• CONTEXT.md 仅作为术语表使用。不要将其用作实现规范、草稿、待办事项、决策日志或会议记录。
• 术语确定后，在 CONTEXT.md 中及时更新。条目应简短、稳定，并对未来的 Agent 有用。
• 产品含义由用户决定。可以建议更清晰的表达，但替换有争议的术语前，必须先征求用户同意。

建模流程

1. 确定当前上下文。如果存在 CONTEXT-MAP.md，请据此查找相关限界上下文。否则，参考根目录下的 CONTEXT.md 和代码库。
2. 提取当前对话、文档、工单、界面、API、架构定义和代码中使用的术语。
3. 标出歧义、同义词、冲突，以及含义会随上下文变化的术语。
4. 提出一个聚焦的问题，以消除最重要的歧义。
5. 给出建议的术语或定义，并说明支持该建议的场景。
6. 用户接受或澄清术语后，如果内容值得长期保留，就更新术语表条目。
7. 重复以上步骤，直到领域模型足以支持当前的规划或实现决策。

术语表格式

使用简洁的 Markdown 条目：

# Context

## Glossary

### <Term>

Definition: <one or two sentences>

Use when: <short concrete usage rule>

Do not use for: <nearby concept or common confusion, if useful>

对于多个限界上下文，只有在现有项目已采用该模式时，才优先使用标题或特定上下文的文件。否则，保持根术语表简单，仅在多个上下文确实存在且有用时使用 CONTEXT-MAP.md。

ADR 规范

谨慎提出 ADR。只有同时满足以下三项时才创建：

• 决策难以撤销。
• 如果没有相关背景，该决策会令人意外。
• 有多个可行选项，且它们之间存在真实取舍。

不要为常规实现细节、临时计划或显而易见的局部选择创建 ADR。如果确实需要 ADR，请使用以下路径和格式：docs/adr/<yyyy-mm-dd>-<slug>.md：

# <Decision>

## Status

Proposed | Accepted | Superseded

## Context

What forced this decision, including relevant domain language.

## Decision

The chosen option.

## Consequences

What this enables, constrains, or makes harder.

## Options Considered

- <Option>: benefit and drawback.

除非用户明确要求在工作流中编写文档，否则写入 ADR 前请先征求用户同意。