domain-glossary

通用语言术语表

此技能会将持续进行的对话转化为一份 DDD 风格的通用语言文档。它会扫描领域术语、消除歧义、提出规范名称，并在工作目录中将不断完善的术语表写入 DOMAIN_GLOSSARY.md。

适用场景

在以下情况下使用此技能：

• 你正在讨论某个领域、功能、产品或系统，并希望使用共同语言。
• 你提到“通用语言”、“领域模型”或“DDD”。
• 你总是被多义术语（“账户”、“用户”、“客户”）弄糊涂，并希望明确这些术语的含义。

随着对话推进，你可以重新运行此技能，以保持术语表更新。

流程

1. 扫描对话和上下文

   • 阅读当前对话，以及任何附带文档或 PRD，查找与领域相关的名词、动词和概念。
   • 忽略通用技术术语（数组、函数、端点），除非它们在此处具有领域含义。

2. 发现语言问题

   找出并记录以下情况：

   • 同一个词被用于指代不同概念（歧义）。
   • 不同的词被用于指代同一个概念（同义词）。
   • 术语含义模糊、多义或使用不一致。

3. 提出规范术语表

   • 为每个概念选择一个规范术语，并明确主张采用哪些名称。
   • 为每个术语撰写简洁的一句话定义，说明它是什么，而不是如何实现。
   • 列出“应避免的别名”，让所有人都清楚在此上下文中哪些术语应当弃用。

4. 按章节对术语分组

   • 将相关术语归入各个标题下（例如“订单生命周期”、“人员”、“计费”、“内容模型”）。
   • 每组都使用单独的 Markdown 表格，列为：Term、Definition、Aliases to avoid。
   • 如果所有术语都属于同一个紧密关联的类别，使用一个表格即可——不要为了分组而生造类别。

5. 描述关系

   • 添加“关系”章节，用通俗语言描述关键术语之间的关系。
   • 使用加粗的术语名称，并在明确时注明简单的基数关系（例如“一个 订单有多个订单项”）。

6. 编写对话示例

   • 编写一段开发者与领域专家之间的简短对话（3–5 轮）。
   • 始终使用规范术语，并展示这些术语在真实场景中如何相互关联。
   • 用这段对话阐明容易混淆的术语之间的界限。

7. 编写或更新 DOMAIN_GLOSSARY.md

   • 如果文件不存在，则按照上述结构创建。
   • 如果文件已存在，则先阅读，再合并新的理解并就地更新。

再次运行

在同一代码库或对话中再次调用时：

1. 阅读现有的 DOMAIN_GLOSSARY.md。
2. 合并上次运行后引入的新术语。
3. 在理解明显发生变化时更新定义。
4. 为已更改的条目标注“(updated)”，为新条目标注“(new)”。
5. 将观察到的任何新歧义添加到“已标记的歧义”。
6. 更新对话示例，使其反映最新的术语和关系。

输出格式

DOMAIN_GLOSSARY.md 大致应遵循以下模式（可按需调整）：

# Ubiquitous Language

## <Domain cluster 1>

| Term | Definition | Aliases to avoid |
|------|------------|------------------|
| **Order** | A customer's request to purchase one or more items | Purchase, transaction |
| **Invoice** | A request for payment sent to a customer after delivery | Bill, payment request |

## <Domain cluster 2>

| Term | Definition | Aliases to avoid |
|------|------------|------------------|
| **Customer** | A person or organization that places orders | Client, buyer, account |
| **User** | An authentication identity in the system | Login, account |

## Relationships

- An **Invoice** belongs to exactly one **Customer**.
- An **Order** produces one or more **Invoices**.

## Example dialogue

> **Dev:** "When a **Customer** places an **Order**, do we create the **Invoice** immediately?"
> **Domain expert:** "No — an **Invoice** is generated only once a **Shipment** is fulfilled."
> ...

## Flagged ambiguities

- "account" is being used to mean both **Customer** and **User**. Prefer **Customer** for the business entity and **User** for authentication.

（使用当前领域中的实际术语，而非这些占位内容。）

行为与规则

1. 明确主张。当多个术语指代同一概念时，选定一个规范词，并将其他术语归入“应避免的别名”。
2. 保持定义简洁。每条定义只用一句话，聚焦于身份（“它是什么”），而非流程（“它如何运作”）。
3. 只包含领域术语。跳过通用基础设施词汇，除非它们在此处具有特殊含义。
4. 指明冲突。将含糊或多义的术语列入“已标记的歧义”，并给出明确建议。
5. 在后续对话中使用术语表。编写或更新文件后，后续对话应始终使用规范术语。