ubiquitous-language

通用语言

从当前对话中提取并规范化领域术语，形成一致的术语表，并保存到本地文件。

流程

1. 扫描对话中与领域相关的名词、动词和概念
2. 识别问题：
   • 同一个词用于不同概念（歧义）
   • 不同词用于同一个概念（同义词）
   • 含义模糊或过度承载的术语
3. 提出规范术语表，明确选定首选术语
4. 使用以下格式，将内容写入工作目录中的 UBIQUITOUS_LANGUAGE.md
5. 在对话中直接输出摘要

输出格式

编写具有以下结构的 UBIQUITOUS_LANGUAGE.md 文件：

# Ubiquitous Language

## Order lifecycle

| 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 |

## People

| 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 only generated once a **Fulfillment** is confirmed. A single **Order** can produce multiple **Invoices** if items ship in separate **Shipments**."
> **Dev:** "So if a **Shipment** is cancelled before dispatch, no **Invoice** exists for it?"
> **Domain expert:** "Exactly. The **Invoice** lifecycle is tied to the **Fulfillment**, not the **Order**."

## Flagged ambiguities

- "account" was used to mean both **Customer** and **User** — these are distinct concepts: a **Customer** places orders, while a **User** is an authentication identity that may or may not represent a **Customer**.

规则

• 要有明确立场。 如果同一个概念存在多个称谓，请选择最佳术语，并将其余称谓列为应避免使用的别名。
• 明确标记冲突。 如果某个术语在对话中存在歧义，请在该术语的“已标记的歧义”部分中指出，并给出明确建议。
• 仅纳入与领域专家相关的术语。 除非模块名或类名在领域语言中具有特定含义，否则将其跳过。
• 定义要简洁。 最多一句话。说明它是什么，而不是它做什么。
• 展示关系。 使用粗体术语名称，并在关系明显时标明数量关系。
• 仅纳入领域术语。 除非通用编程概念（如数组、函数、端点）具有特定领域含义，否则将其跳过。
• 在出现自然聚类时，将术语分成多个表格，例如按子领域、生命周期或参与者划分。每组使用各自的标题和表格。如果所有术语都属于一个紧密关联的领域，一个表格即可——不要强行分组。
• 编写示例对话。 使用开发者与领域专家之间的简短对话（3–5 轮交流），自然展示这些术语如何配合使用。对话应阐明相关概念之间的边界，并展示术语的精确用法。

示例对话

开发者： “如何在不使用 Docker 的情况下测试同步服务？”

领域专家： “请改用文件系统层，而不是 Docker 层。它实现相同的沙箱服务接口，但使用本地目录作为沙箱。”

开发者： “那么，同步导入仍会创建捆绑包并将其解包吗？”

领域专家： “完全正确。同步服务不知道自己正在与哪一层交互。它会调用 exec 和 copyIn——文件系统层只会将二者作为本地 Shell 命令运行。”

再次运行

再次在同一对话中调用时：

1. 读取现有的 UBIQUITOUS_LANGUAGE.md
2. 纳入后续讨论中出现的新术语
3. 根据新的理解更新定义
4. 重新标记所有新出现的歧义
5. 重写示例对话，以纳入新术语