ubiquitous-language

name	ubiquitous-language
description	从当前对话中提取一份 DDD 风格的 ubiquitous language glossary，标出歧义并提出规范术语，保存到 UBIQUITOUS_LANGUAGE.md。适用于用户希望定义 domain terms、建立 glossary、收紧术语、创建 ubiquitous language，或提到“domain model”或“DDD”的场景。
disable-model-invocation	true

Ubiquitous Language

从当前对话中提取并规范 domain terminology，形成一致的 glossary，并保存到本地文件。

流程

1. 扫描对话，寻找与 domain 有关的 nouns、verbs 和 concepts
2. 识别问题：
   • 同一个词被用于不同 concepts（歧义）
   • 不同词指向同一个 concept（同义词）
   • 含糊或负载过多的术语
3. 提出规范 glossary，明确选择推荐术语
4. 按下文格式写入工作目录中的 UBIQUITOUS_LANGUAGE.md
5. 在对话中输出摘要

输出格式

写入采用以下结构的 UBIQUITOUS_LANGUAGE.md：

# Ubiquitous Language

## Order 生命周期

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

## 参与者

| 术语 | 定义 | 应避免的别名 |
| --- | --- | --- |
| **Customer** | 下达 Order 的个人或组织 | Client、buyer、account |
| **User** | 系统中的身份验证主体 | Login、account |

## 关系

- 一张 **Invoice** 只属于一个 **Customer**
- 一个 **Order** 会产生一张或多张 **Invoices**

## 示例对话

> **开发者：**“**Customer** 下达 **Order** 时，需要立即创建 **Invoice** 吗？”
> **领域专家：**“不需要。只有确认 **Fulfillment** 后才生成 **Invoice**。如果商品分成多个 **Shipments** 发出，一个 **Order** 可以产生多张 **Invoices**。”
> **开发者：**“那么 **Shipment** 在发货前取消时，就不会产生对应的 **Invoice**？”
> **领域专家：**“对。**Invoice** 的生命周期与 **Fulfillment** 关联，不直接跟随 **Order**。”

## 已发现的歧义

- “account” 同时被用于表示 **Customer** 和 **User**。两者是不同概念：**Customer** 下达 Orders；**User** 是身份验证主体，不一定代表某个 **Customer**。

规则

• 明确作出选择。 同一个 concept 存在多个词时，选出最佳用词，并把其余词列入需要避免的 aliases。
• 明确标出冲突。 某个词在对话中的使用存在歧义时，把它写入 “Flagged ambiguities”，并给出清晰建议。
• 只收录 domain experts 关心的术语。 Module 或 class names 如果没有 domain language 含义，不要收录。
• 定义保持紧凑。 最多一句话。说明它是什么，不要说明它做什么。
• 展示 relationships。 使用粗体 term names；cardinality 明确时也要写出。
• 只收录 domain terms。 通用编程概念（array、function、endpoint）没有 domain-specific meaning 时不要收录。
• 自然形成分组时使用多个 tables。 可以按 subdomain、lifecycle 或 actor 分组，每组使用独立 heading 和 table。全部 terms 属于同一 cohesive domain 时，一个 table 即可，不要强行拆组。
• 编写 example dialogue。 写一段开发者与 domain expert 之间的简短对话（3–5 轮），展示这些 terms 如何自然配合。对话应明确相关 concepts 的边界，并准确使用术语。

Example dialogue

开发者：“不使用 Docker 时，怎样测试 sync service？”

领域专家：“提供 filesystem layer，不要使用 Docker layer。两者实现同一个 Sandbox service interface，但 filesystem layer 以本地目录作为 sandbox。”

开发者：“这样一来，sync-in 仍然会创建并解压 bundle 吗？”

领域专家：“对。sync service 不知道当前连接的是哪一种 layer；它只调用 exec 和 copyIn，filesystem layer 会把这些调用转换成本地 shell 命令。”

再次运行

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

1. 读取现有 UBIQUITOUS_LANGUAGE.md
2. 纳入后续讨论中出现的新 terms
3. 理解发生变化时更新 definitions
4. 标出新出现的 ambiguities
5. 重写 example dialogue，纳入新 terms