ubiquitous-language

name	ubiquitous-language
description	从当前对话中提取 DDD 风格的通用语言（Ubiquitous Language）词汇表，标记歧义并提出规范术语。保存到 UBIQUITOUS_LANGUAGE.md。当用户想要定义领域术语、构建词汇表、强化术语体系、创建通用语言，或提到"领域模型"或"DDD"时使用。
disable-model-invocation	true

通用语言（Ubiquitous Language）

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

流程

1. 扫描对话，查找与领域相关的名词、动词和概念
2. 识别问题：
   • 同一个词用于不同的概念（歧义）
   • 不同的词用于同一个概念（同义词）
   • 模糊或过载的术语
3. 提出规范词汇表，提供有倾向性的术语选择
4. 写入 UBIQUITOUS_LANGUAGE.md 到工作目录，使用以下格式
5. 在对话中输出摘要

输出格式

编写 UBIQUITOUS_LANGUAGE.md 文件，结构如下：

# 通用语言

## 订单生命周期

| 术语          | 定义                                              | 应避免的别名            |
| ------------- | ------------------------------------------------- | ----------------------- |
| **Order**     | 客户购买一个或多个商品的请求                       | Purchase, transaction   |
| **Invoice**   | 交付后发送给客户的付款请求                         | Bill, payment request   |

## 人员

| 术语            | 定义                                  | 应避免的别名             |
| --------------- | ------------------------------------- | ------------------------ |
| **Customer**    | 下订单的个人或组织                     | Client, buyer, account   |
| **User**        | 系统中的认证身份                       | Login, account           |

## 关系

- 一个 **Invoice** 属于且仅属于一个 **Customer**
- 一个 **Order** 产生一个或多个 **Invoices**

## 示例对话

> **Dev：**"当 **Customer** 下了一个 **Order**，我们会立即创建 **Invoice** 吗？"
> **领域专家：**"不——**Invoice** 只有在 **Fulfillment** 确认后才会生成。如果商品分多个 **Shipments** 发货，一个 **Order** 可以产生多个 **Invoices**。"
> **Dev：**"那么如果 **Shipment** 在发货前被取消，就不会有对应的 **Invoice** 了？"
> **领域专家：**"正是。**Invoice** 的生命周期与 **Fulfillment** 绑定，而不是与 **Order** 绑定。"

## 已标记的歧义

- "account" 被用来既指代 **Customer** 又指代 **User**——这是两个不同的概念：**Customer** 下订单，而 **User** 是一种认证身份，可能代表也可能不代表一个 **Customer**。

规则

• 要有倾向性。 当同一个概念有多个词时，选择最好的一个，将其他列为应避免的别名。
• 明确标记冲突。 如果某个术语在对话中被歧义使用，在"已标记的歧义"部分明确指出，并给出清晰的建议。
• 仅包含领域专家相关的术语。 除非模块或类的名称在领域语言中有意义，否则跳过。
• 保持定义简洁。 最多一句话。定义它是什么，而不是它做什么。
• 展示关系。 使用加粗的术语名称，并在明显的地方表达基数关系。
• 仅包含领域术语。 跳过通用编程概念（array、function、endpoint），除非它们具有领域特定的含义。
• 将术语分组到多个表格中，当自然聚类出现时（例如按子域、生命周期或角色分组）。每个分组有自己的标题和表格。如果所有术语属于同一个内聚的领域，一个表格就够了——不要强行分组。
• 编写示例对话。 一段简短的对话（3-5 轮），在开发者和领域专家之间展示术语如何自然地交互使用。对话应澄清相关概念之间的边界，并展示术语的精确使用。

示例对话

Dev："我如何在没有 Docker 的情况下测试 sync service？"

领域专家："提供 filesystem layer 来代替 Docker layer。它实现了相同的 Sandbox service 接口，但使用本地目录作为 sandbox。"

Dev："那么 sync-in 仍然会创建 bundle 并解包？"

领域专家："没错。sync service 并不知道它正在与哪个 layer 通信。它调用 exec 和 copyIn——filesystem layer 只是将这些作为本地 shell 命令执行。"

重新运行

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

1. 读取已有的 UBIQUITOUS_LANGUAGE.md
2. 合并后续讨论中的新术语
3. 如果理解有所演变，更新定义
4. 重新标记任何新的歧义
5. 重写示例对话以纳入新术语