统一语言（Ubiquitous Language）

用途：术语漂移、需求与实现不一致、跨团队沟通反复返工时查阅

定义

统一语言指在某一个限界上下文内，业务人员、需求分析与开发者共同使用并强制遵守的一套词汇及其语义，并且这套词汇直接出现在代码、事件名与测试用例中，而不只存在于文档里。

它包含三层含义：术语的含义唯一；术语的作用域明确（限定在某个上下文）；术语与模型、代码是同一套，不允许“业务说一套、代码写一套”。

Eric Evans 在《领域驱动设计》中把 DDD 的基石概括为两件事：知识提炼与语言。动机来自一种普遍现象——信息在传递链上逐级失真：

业务专家的认知 → 需求文档 → 设计模型 → 代码实现 → 界面文案

每一次翻译都是一次有损压缩。业务说“申请单”，需求写成“采购请求”，数据库建表 t_request_head，代码里叫 OrderForm，测试用例又用第三个词。等到缺陷出现时，已经没人能确定这四个词指的是不是同一个东西。

统一语言的目的是取消翻译：让模型成为唯一表述，需求讨论、代码命名、测试描述共用同一套词，从而把沟通成本转成一次性的术语治理成本。

作用域是限界上下文，不是全公司。 同一个词在不同上下文有不同含义是正常且应当被允许的，正确做法是显式标注作用域（“订单（销售上下文）”），而不是强行统一成全公司一个定义。
它约束的是写模型。 报表字段、界面文案可以保留历史叫法，但领域模型、事件命名与应用服务方法名必须使用统一语言。
需要治理机制，不会自然形成。 常见机制：新术语必须评审后才能进代码；对含糊词（“管理”“处理”“维护”“配置”）一律要求给出具体动词；发现同一概念两种叫法时立即裁决并记录。
它不是数据字典。 数据字典描述存储结构与字段类型，统一语言描述业务语义与规则边界，两者不可互相替代。
它必须可检查。 判断是否真的落地，只看一件事：把代码里的类名、方法名、事件名念给业务方听，对方能否准确复述其含义。

形态	做法	适用
术语表进仓库	在仓库内维护 `docs/glossary.md`，每条含定义、所属上下文、同义词禁用列表	任何规模
概念-代码映射表	术语 ↔ 类/聚合/事件的对照，评审时逐条核对	中大型系统
事件目录	领域事件按过去式统一命名并登记（`OrderShipped`）	事件驱动系统
命名规范约束	禁用 `Manager`/`Handler`/`Util` 承载业务语义；动词表限定	团队初期
术语评审会	需求评审时专门讨论“这个词到底指什么”，产出裁决记录	业务复杂域

概念	关系
限界上下文	上下文是统一语言的作用域；语言边界与模型边界互为因果
子域划分	核心域值得投入术语治理，通用域直接采用行业标准词汇
上下文映射	跨上下文协作本质是翻译问题，映射模式定义了由谁翻译
事件风暴	常用采集手段：便签上的名词与动词就是统一语言的候选集
模型驱动设计	语言落到代码的形式：类与方法名即术语

适用：业务规则多变、需要业务专家持续参与、跨团队协作、存在历史系统需要长期共存。

不适用或低收益：术语本身已由行业标准固定（如金融报文协议）、纯技术组件（缓存、网关）、生命周期极短的一次性系统。这类场景强行治理只会增加流程。