ubiquitous-language

Ubiquitous Language

Extract domain terms from the current conversation and normalize them into a consistent glossary, saving it to a local file.

Process

Scan the conversationfor domain-relevant nouns, verbs, and concepts
Identify problems：
- The same word used for different concepts (ambiguity)
- Different words used for the same concept (synonyms)
- Vague or overloaded terms
Propose a canonical glossary, making opinionated terminology choices
Write to UBIQUITOUS_LANGUAGE.md, saving it to the working directory using the following format
Output a summary in the conversation

Output Format

Write to UBIQUITOUS_LANGUAGE.md file using the following structure:

# 通用语言

## 订单生命周期

| 术语         | 定义                         | 应避免的别名          |
| ------------ | ---------------------------- | --------------------- |
| **订单**     | 客户购买一件或多件商品的请求 | 购买、交易            |
| **发票**     | 发货后发送给客户的付款请求   | 账单、付款请求        |

## 人员

| 术语       | 定义                                   | 应避免的别名         |
| ---------- | -------------------------------------- | -------------------- |
| **客户**   | 下订单的个人或组织                     | 客户方、买家、账户   |
| **用户**   | 系统中的身份认证标识                   | 登录、账户           |

## 关系

- 一张**发票**属于且仅属于一个**客户**
- 一个**订单**生成一张或多张**发票**

## 示例对话

> **开发者：**"当一个**客户**下了一个**订单**，我们是立刻创建**发票**吗？"
> **领域专家：**"不——**发票**只有在**履约**确认后才生成。如果商品分多次**发货**，一个**订单**可以产生多张**发票**。"
> **开发者：**"所以如果一个**发货**在派送前被取消，就不会有对应的**发票**？"
> **领域专家：**"没错。**发票**的生命周期与**履约**绑定，而不是与**订单**绑定。"

## 标记的歧义

- "账户"曾被用来同时指代**客户**和**用户**——这是两个不同的概念：**客户**下订单，而**用户**是一个身份认证标识，可能不代表某个**客户**。

Rules

Be opinionated. When multiple words exist for the same concept, choose the best one and list the rest as aliases to avoid.
Mark conflicts explicitly. If a term is used ambiguously in the conversation, point it out in the "Flagged Ambiguities" section and give a clear recommendation.
Include only terms that are meaningful to domain experts. Skip module or class names unless they have meaning in the domain language.
Keep definitions concise. At most one sentence. Define what it is, not what it does.
Show relationships. Use bolded term names and express cardinality relationships where obvious.
Include only domain terms. Skip generic programming concepts (arrays, functions, endpoints) unless they have domain-specific meaning.
When clusters emerge naturally, organize terms into multiple tables(e.g., grouped by subdomain, lifecycle, or role). Each group has its own heading and table. If all terms belong to the same coherent domain, one table is enough—do not force grouping.
Write an example dialogue. A short dialogue (3-5 turns) between a developer and a domain expert showing how the terms naturally interact. The dialogue should clarify the boundaries between related concepts and show what it looks like when terms are used precisely.

Example Dialogue

Developer:"How do I testthe sync service？"

Domain Expert:"Provide afilesystem layerinstead of aDocker layer. It implements the samesandbox serviceinterface, but uses a local directory as thesandbox。"

Developer:"So sync-in will still create apackageand unpack it?"

Domain Expert:"Exactly.The sync servicedoesn't know which layer it's talking to. It calls exec and copyIn——the filesystem layerjust executes these as local shell commands."

Re-run

When invoked again in the same conversation:

Read the existing UBIQUITOUS_LANGUAGE.md
incorporate any new terminology into the subsequent discussion
if the understanding has evolved, update the definitions
re-flag any new ambiguities
rewrite the example dialogue to incorporate the new terminology