ubiquitous-language

name	ubiquitous-language
description	从当前对话中提取 DDD 风格的通用语言术语表, 标记歧义并提出规范术语. 保存到 UBIQUITOUS_LANGUAGE.md. 当用户想要定义领域术语, 构建术语表, 强化术语, 创建通用语言, 提到 "通用语言", "术语表", "domain model" 或 "DDD" 时使用.
disable-model-invocation	true

通用语言

从当前对话中提取和形式化领域术语为一致的术语表, 保存到本地文件.

流程

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

## 示例对话

> **开发者:** "当 **Customer** 下 **Order** 时, 我们是否立即创建 **Invoice**?"
> **领域专家:** "不 -- **Invoice** 仅在确认 **Fulfillment** 后生成. 如果商品分多个 **Shipments** 发货, 单个 **Order** 可以产生多个 **Invoices**."
> **开发者:** "所以如果 **Shipment** 在发货前被取消, 就不存在 **Invoice** 了?"
> **领域专家:** "完全正确.** Invoice** 生命周期与 **Fulfillment** 绑定, 而不是与 **Order** 绑定."

## 标记的歧义

- "account" 被用来表示 **Customer** 和 **User**  -- 这是不同的概念:** Customer** 下订单, 而 **User** 是身份验证标识, 可能代表也可能不代表 **Customer**.

规则

• 要有主见. 当同一概念存在多个词时, 选择最好的一个并将其他词列为要避免的别名.
• 明确标记冲突. 如果对话中某个术语使用不明确, 在 "标记的歧义" 部分指出, 并提供明确的建议.
• 仅包含与领域专家相关的术语. 跳过模块或类的名称, 除非它们在领域语言中有意义.
• 保持定义紧凑. 最多一句话. 定义它是什么, 而不是它做什么.
• 显示关系. 使用粗体术语名称并在明显的地方表达基数.
• 仅包含领域术语. 跳过通用编程概念(array, function, endpoint), 除非它们有特定的领域意义.
• 将术语分组到多个表中, 当自然的聚类出现时(例如按子域, 生命周期或角色). 每个组获得自己的标题和表. 如果所有术语属于单个连贯的领域, 一个表就可以了 -- 不要强制分组.
• 编写示例对话. 开发者和领域专家之间的简短对话(3-5 次交换), 展示术语如何自然地相互作用. 对话应该澄清相关概念之间的边界, 并展示术语被精确使用.

示例对话

开发者: "如何在没有 Docker 的情况下测试 sync service?"

领域专家: "提供 filesystem layer 而不是 Docker layer. 它实现相同的 Sandbox service 接口, 但使用本地目录作为 sandbox."

开发者: "所以 sync-in 仍然创建 bundle 并解压它?"

领域专家: "完全正确.sync service 不知道它在和哪个层交谈. 它调用 exec 和 copyIn -- filesystem layer 只是将它们作为本地 shell 命令运行."

重新运行

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

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