领域驱动设计-软件核心复杂性应对之道：第二章

第二章 语言的交流和使用

2.1 模式

​ 由于语言上存在鸿沟，领域专家们只能模糊地描述他们想要的东西。开发人员虽然努力去理解一个自己不熟悉的领域，但也只能形成模糊的认识。有少数的团队成员会学着同时说这两种语言，但由于这样的人太少了，信息流会遭遇瓶颈问题，而且他们的翻译也不准确。

​ 如果语言支离破碎，项目必将遭遇严重问题。领域专家使用他们自己的行话，而技术团队成员则使用自己的语言来从设计角度讨论领域。

​ 日常讨论所使用的术语与代码（软件项目的最重要产品）中使用的术语不一致。甚至同一个人在讲话和写东西时使用的语言也不一致，这导致的后果是，即使人们对领域有了一些深刻的描述，也转眼就忘记了，而无法记录到代码或文档中。

​ 翻译使得沟通不畅，并导致知识消化变得困难。

​ 然后任何一种行话都不能成为公共语言，因为它们无法满足所有的需求。

​ 所有开发人员都应该使用基于模型的语言来描述系统中的工作、任务和功能。语言的使用越普遍，理解就越容易。

​ 团队一致使用通用语言可以暴露出模型中存在的缺点，这样团队就可以尝试并找到不恰当术语或组合词的替代词。当有些概念无法用现有语言中的词汇表达时，新的词语将被引入到讨论中。这些语言上的更改也会在领域模型中引起相应的更改，并促使团队更新类图并重命名代码中的类和方法，甚至在术语的意义改变时会导致行为也发生改变。

​ 通过在实现的上下文中使用这种语言，开发人员能够指出不准确和矛盾的词，并和领域专家一起找到有效的替代词。

​ 当然，领域专家所讲的话会超出通用语言的范围，他们会解释并给出一个更广泛的上下文。但在模型的范围内，他们应该使用language，并在发现那些拗口、不完整或错误的地方之后要特别留意。通过一致地使用基于模型的语言并不断完善它，直到它达到非常流程的程度，我们就可以得到一个完整的、易于理解的模型，它完全由简单元素组成，这些简单元素组合到一起表达了复杂的思想。

因此：

​ 将模型作为语言的中心。确保团队在所有交流活动和代码中坚持使用这种语言。在画图，写东西特别是讲话时也要使用这种语言。

​ 通过尝试不同的表示方法（它们反映了不同模型）来消除难点。然后重构代码，并对类、方法和模块重新命名，以便与新模型相一致。解决交谈中的术语混淆问题，就像我们对普通词汇形成一个公认的理解一样。

​ 要认识到通用语言中的更改就是对模型的更改。

​ 领域专家应该避免使用拗口或无法表达领域理解的术语或结构，开发人员应该密切监视那些将会妨碍设计的有歧义和不一致的地方。

在每个对话场景中，注意观察讲话者有多少内容是谈论软件的业务功能，有多少内容是从技术上谈论软件的工作 机理的。用户和开发人员用的是同一种语言吗？它是否是一种可以用来讨论应用程序功能的丰富语言？

2.2 大声地建模

当我们在讨论中使用领域模型的通用语言时，特别是在开发人员和领域专家一起仔细研究场景和需求的讨论中，通用语言的使用会越来越流利，而且我们还可以互相指定一些细微的差别。我们很自然地一起使用这种语言，而图和文档永远也无法实现这种效果。

讨论系统时要结合模型。使用模型的元素以及模型中各元素之间的交互来大声描述场景，并且按照模型允许的方式将各种概念结合到一起。找到更简单的表达方式来讲出你要讲的话，然后将这些新的思想应用到图和代码中。

2.3 一个团队，一种语言

​ 当领域专家使用这种语言互相讨论，或者域开发人员进行讨论时，很快就会发现模型中哪些地方不符合他们的需要，甚至是错误的。由于基于模型的语言要求十分精确，因此领域专家也将发现他们的想法中的一些矛盾和含糊之处。

​ 开发人员和领域专家可以通过一步一步地使用模型对象来走查场景，从而对模型进行非正式的测试。每次讨论都是开发人员和专家一起使用模型的机会，在这个过程中，他们可以互相加深理解，并对概念进行精化。

​ 领域专家可以使用模式语言来编写用例，甚至可以直接利用模型来指定验收测试。

2.4 文档和图

UML图无法传达模型的两个最重要的方面，一个方面是模型所表示的概念的意义，另一个方面是对象应做哪些事情。但是，这并不是大问题，因为仔细使用英语就可以很好地完成这项任务。

图是一种沟通和解释手段，它们可以促成头脑风暴活动。简洁的小图能够很好地实现这些目标。使用简化的图，图中只包含对象模型的重要概念部分，这些部分对于理解设计至关重要。

设计的重要细节应该在代码中体现出来。良好的实现应该是透明的，清楚地展示它的底层模型。互为补充的图和文档能够引导人们将注意力放在核心要点上。

务必要记住 模型不是图，图的目的是帮助表达和解释模型。代码可以充当设计细节的存储库。

1. 书面设计文档

一旦文档变成持久形式，往往就会从项目进展流程中脱离出来。它会跟不上代码或项目语言的演变。

文档应作为代码和口头交流的补充，极限编程不主张使用过多的设计文档，而让代码解释它自己。实际运行的代码不会说话，而其他文档则不然。运行代码所产生的行为是明确的。

​ 代码作为一种设计文档，自身也存在局限性。它可能会把读代码的人淹没在细节中。尽管代码的行为是非常明确的，但这并不意味着通过读代码就能显而易见地看出行为。而且行为的意义可能更难表示.

文档不应再重复表示代码已经明确表达出的内容

文档应该着重说明含义，以便使人们能够深入理解大比例结构，并将注意力集中在核心元素上。当编程语言无法直接明了地实现概念时，文档可以澄清设计意图。

文档应努力寻求生存之道并保持最新

文档必须深入到各种项目活动中去：注意听通用语言，观察它是如何变化的。如果设计文档中使用的术语不再出现在讨论和代码中，那么文档就失去了作用。或许是文档太大或太复杂了，或许是它没有突出一个十分重要的主题。人们不再阅读文档，或者对它失去了兴趣。如果文档对通用语言没有影响，那么一定是出问题了。

2. 完全依赖可执行代码的情况

2.5 解释性模型