ubiquitous-language

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Ubiquitous Language

Create or update a DDD-style glossary of domain terms in

UBIQUITOUS_LANGUAGE.md

Inspired by Matt Pocock's deprecated

ubiquitous-language

在

UBIQUITOUS_LANGUAGE.md

中创建或更新DDD风格的领域术语术语表。

灵感来自Matt Pocock已弃用的

ubiquitous-language

Process

流程

Read the current conversation and extract domain-relevant nouns, verbs, roles, lifecycle states, workflows, and business concepts.
If
```
UBIQUITOUS_LANGUAGE.md
```
already exists in the working directory, read it first and update it rather than replacing it blindly.
Inspect nearby domain docs when useful:
```
CONTEXT.md
```
,
```
CONTEXT-MAP.md
```
,
```
docs/
```
,
```
docs/adr/
```
,
```
specs/
```
, and README files.
Detect terminology problems:
- one word used for multiple concepts
- multiple words used for one concept
- vague, overloaded, or implementation-shaped terms
- code names that should not leak into the domain language
Pick canonical terms. Be opinionated when the evidence is strong.
Write or update
```
UBIQUITOUS_LANGUAGE.md
```
.
Return a short summary of terms added, terms renamed, ambiguities flagged, and open questions.

Do not run an interview before writing the first draft. If something is unclear, document it in

Open Questions

读取当前对话，提取与领域相关的名词、动词、角色、生命周期状态、工作流和业务概念。
如果工作目录中已存在
```
UBIQUITOUS_LANGUAGE.md
```
，先读取该文件并进行更新，而非盲目替换。
必要时查看相关领域文档：
```
CONTEXT.md
```
、
```
CONTEXT-MAP.md
```
、
```
docs/
```
、
```
docs/adr/
```
、
```
specs/
```
以及README文件。
检测术语问题：
- 同一词汇用于多个概念
- 多个词汇指代同一概念
- 模糊、过载或带有实现导向的术语
- 不应渗透到领域语言中的代码命名
选择标准术语。当证据充分时，需明确立场。
编写或更新
```
UBIQUITOUS_LANGUAGE.md
```
。
返回新增术语、重命名术语、标记的歧义点以及待解决问题的简短摘要。

不要在撰写初稿前进行访谈。如有不明确之处，将其记录在「待解决问题」中。

File Format

文件格式

Use this structure:

markdown

undefined

使用以下结构：

markdown

undefined

Ubiquitous Language

[Domain Area]

[领域区域]

Term	Definition	Aliases to avoid	Notes
Canonical Term	One-sentence definition.	Old name, vague synonym	Clarification or boundary note.

术语	定义	应避免的别名	备注
标准术语	一句话定义。	旧名称、模糊同义词	说明或边界注释。

Relationships

关系

A Term belongs to exactly one Other Term.
A Workflow moves from State A to State B when [domain event].

一个术语仅属于一个其他术语。
当[领域事件]发生时，工作流从状态A转移到状态B。

Example Dialogue

示例对话

Dev: "Question using canonical terms?"

Domain expert: "Answer using canonical terms and clarifying boundaries."

开发人员："使用标准术语提问？"

领域专家："使用标准术语并说明边界来回答。"

Flagged Ambiguities

标记的歧义点

```
term
```
was used to mean both Concept A and Concept B. Prefer Concept A when [condition], and Concept B when [condition].

```
term
```
曾被同时用来指代概念A和概念B。当[条件]时优先使用概念A，当[条件]时优先使用概念B。

Open Questions

待解决问题

[Question that needs a domain expert decision.]

undefined

[需要领域专家决策的问题。]

undefined

Rules

规则

Include only terms meaningful to domain experts.
Skip generic programming terms unless the term has domain meaning in this project.
Include operational short codes and abbreviations when domain users use them, such as
```
DN
```
for Delivery Note.
Do not treat an abbreviation as a separate concept when it is only a short name for a canonical term. Put it in
```
Aliases to avoid
```
or
```
Notes
```
.
Include virtual business concepts when users rely on them operationally, even if they are not physical things.
Do not include file paths, class names, or package names unless they are also real domain terms.
Keep definitions to one sentence.
Define what the term is, not how it is implemented.
Group terms into natural domain areas when there are enough terms.
Use a single table if the domain is still small.
Use bold formatting for canonical terms in relationships and dialogue.
In
```
Aliases to avoid
```
, list words that should not be used for that concept.
If two terms are truly distinct, explain the boundary in
```
Notes
```
or
```
Flagged Ambiguities
```
.
Do not invent business rules. Mark uncertain relationships as open questions.

仅包含对领域专家有意义的术语。
除非术语在本项目中具有领域含义，否则跳过通用编程术语。
当领域用户使用操作短代码和缩写时，需将其包含在内，例如
```
DN
```
代表Delivery Note。
如果缩写只是标准术语的简称，不要将其视为单独的概念。将其放在「应避免的别名」或「备注」中。
当用户在操作中依赖虚拟业务概念时，需将其包含在内，即使它们不是物理实体。
除非文件路径、类名或包名同时也是真实的领域术语，否则不要将其包含在内。
定义限制为一句话。
定义术语是什么，而非其实现方式。
当术语足够多时，将其分组到自然的领域区域中。
如果领域范围仍较小，使用单个表格。
在关系和对话中对标准术语使用加粗格式。
在「应避免的别名」中列出不应用于该概念的词汇。
如果两个术语确实不同，在「备注」或「标记的歧义点」中说明边界。
不要凭空创造业务规则。将不确定的关系标记为待解决问题。

Examples

示例

Use examples like these as shape guidance. Do not copy them unless they match the current project.

markdown

undefined

使用以下示例作为格式参考。除非与当前项目匹配，否则不要复制。

markdown

undefined

Logistics

物流

Term	Definition	Aliases to avoid	Notes
Delivery Note	A document that records goods delivered for a job, order, or shipment.	DN	`DN` is a short code, not a separate concept.
Warehouse On Site	A warehouse location or stock area that exists at an operational site.	WON	`WON` is a short code; confirm whether it means a place, a status, or both.
Operational File	A virtual folder used to group job-related documents, notes, and records.	File, physical folder	This is not necessarily a filesystem directory or physical file.


Example relationships:

```markdown
- A **Delivery Note** belongs to one **Job** or **Shipment**.
- An **Operational File** groups the documents and records needed to complete a **Job**.
- A **Warehouse On Site** may hold stock for one or more active operational workflows.

Example ambiguity:

markdown

- `File` may mean either an **Operational File** in the business workflow or a technical filesystem file. Use **Operational File** for the business concept.

术语	定义	应避免的别名	备注
Delivery Note	记录为某项任务、订单或发货交付的货物的文档。	DN	`DN` 是短代码，并非独立概念。
Warehouse On Site	位于作业现场的仓库位置或库存区域。	WON	`WON` 是短代码；需确认它指代的是地点、状态还是两者皆是。
Operational File	用于分组任务相关文档、笔记和记录的虚拟文件夹。	File, physical folder	它不一定是文件系统目录或物理文件。


示例关系：

```markdown
- 一个**Delivery Note**属于一个**Job**或**Shipment**。
- 一个**Operational File**对完成**Job**所需的文档和记录进行分组。
- 一个**Warehouse On Site**可为一个或多个活跃的作业工作流存放库存。

示例歧义：

markdown

- `File`可能指代业务工作流中的**Operational File**，也可能指代技术层面的文件系统文件。针对业务概念，请使用**Operational File**。

Re-Running

重新执行

When invoked again:

Preserve stable accepted terms unless new context clearly invalidates them.
Add new terms from the conversation or local docs.
Tighten definitions that were previously vague.
Move resolved ambiguities into canonical terms or notes.
Keep unresolved ambiguities visible.

当再次调用时：

保留已被认可的稳定术语，除非新上下文明确证明其无效。
从对话或本地文档中添加新术语。
优化之前模糊的定义。
将已解决的歧义点移入标准术语或备注中。
保留未解决的歧义点，使其可见。

Final Response

最终响应

After writing

UBIQUITOUS_LANGUAGE.md

, respond with:

markdown

Updated `UBIQUITOUS_LANGUAGE.md`.

Added:
- [Term]

Changed:
- [Term or "None"]

Flagged:
- [Ambiguity or "None"]

Open questions:
- [Question or "None"]

编写完

UBIQUITOUS_LANGUAGE.md

后，返回以下内容：

markdown

已更新`UBIQUITOUS_LANGUAGE.md`。

新增：
- [术语]

修改：
- [术语或"无"]

标记：
- [歧义点或"无"]

待解决问题：
- [问题或"无"]