1.2 领域建模：确立共通的语汇

要开始一项领域建模活动，首先要从等待被建模的问题域着手。你要理解域中实体彼此互动及履行各自职责的方式。这项工作要在领域专家和建模人员的协作之下进行。领域专家是内行，他们用领域内的专门用语交流，而且向外界解释领域概念的时候也离不开这套专门用语。建模者懂得如何将对模型的理解表达成一种可被编写成文档、分享并实现成软件的形式。建模者必须能理解领域专家的术语，并将其理解反映到设计的领域模型中去。

之前，我接手过一个对一家大型金融中介机构的后台操作完成建模的项目。我不是那个领域的专家，而且对证券业的业务活动涉及的种种细节和复杂情况所知甚少。经过与领域专家一段时间的合作，我感觉这个领域有足够的代表性，其例子和解释足以作为读者对其他领域建模时的参考。接下来的补充内容“金融中介系统：背景知识”介绍了证券交易和金融中介领域的基本情况，我们将它作为实例来介绍如何实现DSL。随着学习的深入，你将发现一些新的概念及必要的详细内容。如果你不熟悉股票交易也无需担心，我会用补充内容的形式提供足够的背景资料，帮助你了解建模对象的基本概念。

就在需求分析会议开始的第一天，金融业的领域专家开始大谈附息债券、折价债券、抵押、公司行为 。这些词都是金融中介的常用术语，但我完全不知道是什么意思。而且不少词其实是同义词，比如折价债券意思等同零息债券，不同的领域专家会在不同场合交替使用它们。可因为我不懂，混淆的情况层出不穷。在场的不可能都是金融业专家，所以我们很快意识到必须确定一套共通的语汇，以免知识交流会议失去意义。不仅与领域专家的协作要在共通语汇的前提下进行，而且我们要确保设计开发出来的模型基于同一种“语言”——这个领域的自然语言。

金融中介系统：背景知识

金融中介的业务始自一次交易过程。该过程涉及两个以上当事人之间证券与现金的交换，这些当事人称为交易方。在某个确定的日期（称为交易日），交易方承诺在股票交易所这个地点，按照商定的价格（称为单位价格）履行交易（成交）。交易过程的一大支柱——证券（另一支柱是现金）——有多种类型，如股票、债券、共同基金等，许多类型各自又有不同的分类体系。比如，债券又可分为附息债券和折价债券。

在交易日之后规定的天数内，基金或证券的所有权在交易方之间完成转移，这称为结算过程。每种证券都有各自的交易、成交、结算流程，在交易和结算过程中要经历一系列的状态变更。

共通语汇的益处

共通语汇在模型的所有关联方之中共享，作为一股维系力量把组成实现的各部分制品统一起来。更重要的是，有了这套共通语汇，你就可以在项目交付周期的各个阶段轻松跟踪各项特性、功能和对象的变化轨迹。建模者用来编写测试用例的名词术语出现在程序里就是模块的名字，出现在数据模型里就是实体的名字，出现在测试用例里就是对象的名字。以这样的方式，共通语汇成为了架通问题域与解答域的桥梁。在项目前期，建立共通语汇花费的时间可能超过预期，但我几乎可以担保，它将帮助避免更多未来返工的时间。我们来看看共通语汇可以带来的切实的好处。

1. 把共通语汇当做粘合剂

在需求分析阶段，一套共通语汇可充当建模者和领域专家之间互相理解的桥梁，可使讨论更加简明扼要、效率更高。当交易员老鲍提到债券的应计利息时，建模员乔知道他说的债券特指附息债券。

2. 测试用例中的共通词汇

共通语汇还可作为开发测试用例的基础，这样便于领域专家验证测试用例的正确性。在我那个金融中介系统的项目中有这样一个测试用例：对于证券公司蹦蹦高证券以40%价格发行、面值为10 000美元、首次计息日为2001年5月15日的零息债券，投资者应在发行时支付美元4000。这个测试用例无论建模者、测试者还是负责审阅的领域专家都能完全理解，因为它采用了最自然的领域语言作为编写用语。

3. 开发中的共通语汇

如果开发团队用共通语汇来表述程序模块，那么产生的代码也将使用同一种领域语言。如果你提起模块的时候都用“债券交易模块”、“证券结算模块”一类的字眼，那么写代码的时候自然就会用同样的字眼命名领域实体。

在问题域与解答域之间发展出一套共通语汇是走向解答域的第一步。让我们给图1-1添上“共通语汇”这个维系两个领域的粘合剂，结果如图1-2所示。

图1-2　问题域和解答域享有共同的语汇，可降低信息传达的困难度。在共通语汇之下，你可以从问题域的制品追踪到它在解答域的相应表示

你已经知道开发者和领域专家要有共通语汇，但是语言要怎样映射到解答域呢？对于开发者制作的模型，领域专家能理解多少？沟通问题是软件开发生态系统中的常见问题。

看过图1-2，你应该会知道不可能指望领域专家直接理解目前构成解答域的技术制品，他们不具备那样的能力。随着系统复杂度的提高，模型开始膨胀，沟通的障碍也越来越多。可是领域专家其实没必要理解那些与实现模型相关的复杂细节，验证业务规则实现得正不正确才是他们该做的事情。理想情况下，领域专家可以自己编写测试脚本去验证领域规则的实现的正确性及完善程度，但这不是一个现实的方案。

那么有没有可能以共通语汇为基础，为领域专家建立一种沟通模型，并让其他人也都能流利说出领域专家的日常业务用语？可以办到。这正是DSL发挥作用的时刻！