Back to Details

ubiquitous-language

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Ubiquitous Language

通用语言（Ubiquitous Language）

Extract and formalize domain terminology from the current conversation into a consistent glossary, saved to a local file.
从当前对话中提取领域术语并将其规范化为统一的词汇表，保存至本地文件。

Process

流程

  1. Scan the conversation for domain-relevant nouns, verbs, and concepts
  2. Identify problems:
    • Same word used for different concepts (ambiguity)
    • Different words used for the same concept (synonyms)
    • Vague or overloaded terms
  3. Propose a canonical glossary with opinionated term choices
  4. Write to 
    UBIQUITOUS_LANGUAGE.md
     in the working directory using the format below
  5. Output a summary inline in the conversation
  1. 扫描对话，提取与领域相关的名词、动词和概念
  2. 识别问题:
    • 同一词汇用于指代不同概念（歧义）
    • 不同词汇用于指代同一概念（同义词）
    • 模糊或被过度使用的术语
  3. 提出标准词汇表，给出明确的术语选择建议
  4. 按照下方格式将内容写入工作目录下的
    UBIQUITOUS_LANGUAGE.md
    文件
  5. 在对话中直接输出摘要

Output Format

输出格式

Write a 
UBIQUITOUS_LANGUAGE.md
file with this structure:
md
undefined
生成的
UBIQUITOUS_LANGUAGE.md
文件需遵循以下结构：
md
undefined

Ubiquitous Language

Ubiquitous Language

Order lifecycle

Order lifecycle

TermDefinitionAliases to avoid
OrderA customer's request to purchase one or more itemsPurchase, transaction
InvoiceA request for payment sent to a customer after deliveryBill, payment request
TermDefinitionAliases to avoid
OrderA customer's request to purchase one or more itemsPurchase, transaction
InvoiceA request for payment sent to a customer after deliveryBill, payment request

People

People

TermDefinitionAliases to avoid
CustomerA person or organization that places ordersClient, buyer, account
UserAn authentication identity in the systemLogin, account
TermDefinitionAliases to avoid
CustomerA person or organization that places ordersClient, buyer, account
UserAn authentication identity in the systemLogin, account

Relationships

Relationships

  • An Invoice belongs to exactly one Customer
  • An Order produces one or more Invoices
  • An Invoice belongs to exactly one Customer
  • An Order produces one or more Invoices

Example dialogue

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

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.
undefined
  • "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.
undefined

Rules

规则

  • Be opinionated. When multiple words exist for the same concept, pick the best one and list the others as aliases to avoid.
  • Flag conflicts explicitly. If a term is used ambiguously in the conversation, call it out in the "Flagged ambiguities" section with a clear recommendation.
  • Keep definitions tight. One sentence max. Define what it IS, not what it does.
  • Show relationships. Use bold term names and express cardinality where obvious.
  • Only include domain terms. Skip generic programming concepts (array, function, endpoint) unless they have domain-specific meaning.
  • Group terms into multiple tables when natural clusters emerge (e.g. by subdomain, lifecycle, or actor). Each group gets its own heading and table. If all terms belong to a single cohesive domain, one table is fine — don't force groupings.
  • Write an example dialogue. A short conversation (3-5 exchanges) between a dev and a domain expert that demonstrates how the terms interact naturally. The dialogue should clarify boundaries between related concepts and show terms being used precisely.
  • 明确立场：当同一概念有多个词汇表达时，选择最优术语，并将其他词汇列为需避免使用的别名。
  • 明确标记冲突：若对话中某术语存在歧义，需在“标记的歧义点”部分明确指出并给出清晰建议。
  • 定义简洁精准：每条定义不超过一句话。定义需说明术语“是什么”，而非“做什么”。
  • 展示关联关系：术语名称使用加粗格式，若关联基数明确则需说明。
  • 仅包含领域术语：忽略通用编程概念（如array、function、endpoint），除非它们具有领域特定含义。
  • 自然分组术语：当出现自然的术语集群时（如按子领域、生命周期或角色划分），将术语分组到多个表格中。每个分组需有独立标题和表格。若所有术语属于同一紧密关联的领域，使用一个表格即可——不要强行分组。
  • 编写示例对话：一段开发者与领域专家之间的简短对话（3-5轮交流），展示术语如何自然交互。对话需明确相关概念的边界，并体现术语的精准使用。

Re-running

重新执行

When invoked again in the same conversation:
  1. Read the existing 
    UBIQUITOUS_LANGUAGE.md
  2. Incorporate any new terms from subsequent discussion
  3. Update definitions if understanding has evolved
  4. Mark changed entries with "(updated)" and new entries with "(new)"
  5. Re-flag any new ambiguities
  6. Rewrite the example dialogue to incorporate new terms
当在同一对话中再次调用时：
  1. 读取已有的
    UBIQUITOUS_LANGUAGE.md
    文件
  2. 纳入后续讨论中出现的所有新术语
  3. 若对术语的理解有更新，则同步更新定义
  4. 对修改过的条目标记“(updated)”，新增条目标记“(new)”
  5. 重新标记所有新出现的歧义点
  6. 重写示例对话以纳入新术语

Post-output instruction

输出后说明

After writing the file, state:
I've written/updated 
UBIQUITOUS_LANGUAGE.md
. From this point forward I will use these terms consistently. If I drift from this language or you notice a term that should be added, let me know.
写入文件后，需告知用户：
我已编写/更新了
UBIQUITOUS_LANGUAGE.md
。从现在起我将严格使用这些术语。若我偏离了该术语体系，或者您发现有需要添加的术语，请告知我。