DDD之通用语言-技术圈

通用语言和界限上下文（Bounded Context,2）同时构成了DDD的两大支柱，并且它们是相辅相成的。通用语言是有边界范围的，就是在界限上下文之内，通用语言所描述的语义是一致的，出了这个界限上下文语义就有可能改变了。

在开发过程中，最大的鸿沟之一便存在于领域专家和开发者之间。通常来说，领域专家将关注点放在交付业务价值上，而开发者则将注意力放在技术实现上。当然，并不是说开发者的动机是错误的，而是说开发者的眼光被自然而然地吸引到了实现层面上。即便让领域专家和开发者一同工作，他们之间的协作也只是表面的，这时在所开发的软件中便产生了一种映射：将业务人员所想的映射到开发者所理解的。这样一来，软件便不能完全反映出领域专家的思维模型。随着时间的推移，这种鸿沟将增加软件的开发成本。而随着开发者转到其他项目或者离职，本应该驻留在软件中的领域知识也就丢失了。另一个问题发生在当多个领域专家之间存在分歧的时候。这是很有可能发生的，因为每个专家只是熟悉某个或者某些特定的领域。另外，在某个领域里找不到真正的专家也是可能的，此时，有人可能对该领域有所了解，但是他更像一个业务分析员。这些问题将导致相互矛盾的软件模型。更糟的是，软件的技术实现可能错误地改变软件的业务规则。

我们已经能够理解软件开发的最大问题之一便是业务人员和技术人员需要某种翻译才能交流。使领域专家和开发者在一起工作，这样开发出来的软件能够准确地传达业务规则。当然，对于领域专家和开发者来说，这并不表示单单地包容对方，而是将他们组成一个密切协作的团队。“准确传达业务规则”的意思是说，此时的软件就像如果领域专家是编码人员时所开发出来的一样。使用通用语言后在领域专家、开发者和软件本身之间不存在“翻译”，意思是当大家都使用相同的语言进行交流时，每人都能听懂他人所说。

领域专家将和开发人员一起创建一套适用于领域建模的通用语言。通用语言必须在全队范围之内达成一致；所有成员都使用通用语言进行交流，通用语言也是对软件模型的直接反映。请注意，虽然团队中同时包含领域专家和开发人员，但并不是“我们”和“他们”的关系，团队中只有“我们”的概念。通用语言也有助于促使原本存在分歧的领域专家们达成一致意见。此外，通过将领域知识传达给所有的团队成员，包括开发人员，整个团队也将更具凝聚力。我们甚至可以认为，这是每个公司都应该有的对于知识型工作者的起码训练。

通用语言是团队共享的语言。领域专家和开发者使用相同的通用语言进行交流。事实上，团队中每个人都使用相同的通用语言。不管你在团队中的角色如何，只要你是团队的一员，你都将使用通用语言。通用语言是团队自己创建的公用语言，团队中同时包含领域专家和软件开发人员。

如何提炼通用语言呢？

同时绘制物理模型图和概念模型图，并标以名字和行为。虽然这些图并不是正式的设计图，但它们却包含了软件建模的某些方面。即使你的团队在使用统一建模语言（Unified Modeling Language, UML ）来完成正式建模，也不要得意忘形，因为这样可能反而不利于团队的讨论，最终将阻碍通用语言的产生。
创建一个包含简单定义的术语表。将你能想到的术语都罗列出来，包括好的和不好的，并注明好与不好的原因。在你给术语下定义时，你在不经意间就会创造出一些可重用的词汇，因为此时你使用的是领域中的通用语言。

如果你不喜欢术语表，可以采用其他类型的文档，但记得将那些“不正式”的模型图也包含进去。同样，这里最终的目的也是发现通用语言中的术语和词组。
由于团队中有些人工作在术语表上，还有些人工作在文档上，此时你需要找到团队的其他人员来检查你的成果。分歧肯定是有的，你应该对此有所准备。

总结：

这里的“通用”意思是“普遍的”，或者“到处都存在的”。通用语言在团队范围内使用，并且只表达一个单一的领域模型。·
“通用语言”并不表示全企业、全公司或者全球性的万能的领域语言。
界限上下文和通用语言间存在一对一的关系。
界限上下文是一个相对较小的概念，通常比我们起初想象的要小。界限上下文刚好能够容纳下一个独立的业务领域所使用的通用语言。
只有当团队工作在一个独立的界限上下文中时，通用语言才是“通用”的。
虽然我们只工作在一个限界上下文中，但是通常我们还需要和其他限界上下文打交道，这时可以通过上下文映射对这些限界上下文进行集成。每个界限上下文都有自己的通用语言，而有时语言间的术语可能有重叠的地方。
如果你试图将某个通用语言运用在整个企业范围之内，或者更大的、夸企业的范围内，你将失败。