ddd-ubiquitous-language

一句话概述

在一个限界上下文中，建立一套由领域专家、开发人员、代码和测试共同使用的词汇。

何时使用此技能

• 新项目开始构建领域模型时。
• 业务与工程之间的术语长期不一致时。
• 代码中的命名与领域专家的表达不符时。
• 对话与代码之间存在翻译表（“业务说‘发票’时，我们指的是 BillingDocument”）。

何时不使用此技能

• 代码层面的模式问题 → 委派给战术模式技能。
• 跨上下文的术语翻译 → 转交给 ddd-context-mapping。
• 通用的变量和函数命名约定 → 这是代码风格问题，不属于 DDD。

核心内容

通用语言是领域专家和工程师用来讨论模型的、共享且精确的词汇，并且这些词汇会原样出现在代码、测试、数据库和 UI 中。它不是团队约定查阅的术语表，而是他们实际使用和书写的语言。

如何逐步建立通用语言。 倾听领域专家的表达，并原样记录，不要改述。当专家说“结算一笔付款”时，代码中就应有一个名为 settle 的方法，而不是 processPayment。当专家对某个术语意见不一时，要促使他们达成一致——这种分歧隐藏着真正的区别（通常是两个概念被塞进了同一个词里）。

按限界上下文划分。 通用语言在一个限界上下文内保持一致。两个上下文可以用同一个词表达不同的含义，这没有问题——上下文映射负责处理翻译。错误在于试图强制整个企业统一使用一套语言。

朗读测试。 选取一段代码（方法体、测试名称或类层次结构），大声读给领域专家听。如果他们能理解代码的作用，说明语言有效。如果他们问“这是什么意思？”，说明语言已经偏离模型。

决策启发

• 在限界上下文内部应用。避免试图统一整个企业的语言。
• 开发人员自行创造名称（“Manager”“Helper”“Processor”），而不是询问专家该如何称呼这个概念时，要提出异议。
• 坚决消除同义词。在一个上下文中，“Customer”“Client”和“Account”不应同时存在并表示同一事物。

反模式

• 开发人员因为觉得“询问专家太费时间”而自行创造名称。
• 因为各团队偏好不同，就容忍同义词共存。
• 在对话与代码之间维护翻译表——这说明模型存在偏差。
• 将术语表作为独立文档维护，而不是让代码本身成为术语表。

另请参阅

• ddd-bounded-context — 每个上下文使用一套语言；明确边界才能形成连贯的语言。
• ddd-design — 语言是任何设计会议的首要产出。
• ddd-context-mapping — 在不同上下文之间翻译语言。

参考资料

• Evans，《领域驱动设计》（2003），第 2 章（沟通与语言的运用）。