《领域驱动设计：软件核心复杂性应对之道（修订版）》—第2章 2.2节“大声地”建模

本节书摘来自异步社区《领域驱动设计：软件核心复杂性应对之道（修订版）》一书中的第2章，第2.2节“大声地”建模，作者【美】埃里克•埃文斯（eric evans）, 马利伟 , 万龙，更多章节内容可以访问云栖社区“异步社区”公众号查看。

2.2 “大声地”建模

假如将交谈从沟通方式中除去的话，那会是巨大的损失，因为人类本身颇具谈话的天赋。遗憾的是，当人们交谈时，通常并不使用领域模型的语言。

可能开始时你并不认为上述论断是正确的，而且的确有例外情况。但下次你参加需求或设计讨论时，不妨认真听一下。你将听到人们用业务术语或者各种业余术语来描述功能。还会听到人们讨论技术工件和具体的功能。当然，你还会听到来自领域模型的术语；在人们共同使用的那部分业务术语中，那些显而易见的名词在编码时通常被用作对象名称，因此这些术语经常被人们提及。但你是否也听到一些使用当前领域模型中的关系和交互来描述的措辞呢？

30

改善模型的最佳方式之一就是通过对话来研究，试着大声说出可能的模型变化中的各种结构。这样不完善的地方很容易被听出来。

“如果我们向routing service提供出发地、目的地和到达时间，就可以查询货物的停靠地点，嗯……将它们存到数据库中。”（含糊且偏重于技术）

“出发地、目的地……把它们都输入到routing service中，而后我们得到一个itinerary，它包含我们所需的全部信息。”（更具体，但过于啰嗦）

“routing service查找满足route specification的itinerary。”（简洁）

使用单词和短语是极为重要的——其将我们的语言能力用于建模工作，这就如同素描对于表现视觉和空间推理十分重要一样。我们即要利用系统性分析和设计方面的分析能力，也要利用对代码的神秘“感觉”。这些思考方式互为补充，要充分利用它们来找到有用的模型和设计。在所有这些方式中，语言上的试验常常是最容易被忽视的（本书第三部分将深入探讨这种发现过程，并通过几段对话来显示它们之间的相互影响）。

事实上，我们的大脑似乎很擅长处理口语的复杂性（对于像我这样的门外汉，有本好书是steven pinker所著的the language instinct [pinker 1994]）。例如，当具有不同语言背景的人凑在一起做生意时，如果没有公共语言，他们就会创造一种称为“混杂语”（pidgin）的公共语言。混杂语虽然不像讲话者的母语那样详尽，但它适合当前任务。当人们交谈时，自然会发现词语解释和意义上的差别，而后会自然而然地解决这些差别。他们会发现这种语言中的简陋晦涩之处并把它们搞顺畅。

31

上大学时，我曾经修过西班牙语速成课。课堂上规定不准讲英语。起初，令人相当沮丧。这不仅感觉很别扭，而且需要很强的自制力。但最终我和同学们都达到了通过书面练习永远不可能达到的流利程度。

当我们在讨论中使用领域模型的ubiquitous language时，特别是在开发人员和领域专家一起推敲场景和需求时，通用语言的使用会越来越流利，而且我们还可以互相指点一些细微的差别。我们自然而然地共享了我们所说的语言，而这种方式是图和文档无法做到的。

想要在软件项目上产生一种ubiquitous language，说起来容易，做起来却难，我们必须充分利用自然赋予我们的才能来实现这个目标。正如人类的视觉和空间思维能力使我们能够快速传达和处理图形概述中的信息一样，我们也可以利用自己在基于语法的、有意义的语言方面的天赋来推动模型的开发。

因此，下面这段话可作为ubiquitous language模式的补充：

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