Martin Fowler 和 Rebecca Parsons 关于领域特定语言（Domain-Specific Language）的新书

Martin Fowler 先生和 Rebecca J. Parsons 女士在合著的一本新书中对领域特定语言（Domain-Specific Language）进行了探讨。领域特定语言能够给软件工程师带来很多好处，包括提升抽象层次，增强各利益相关人之间的沟通，以及提升生产效率等等。在本书中，作者给领域特定语言所下的定义是：

“一种专注于某个特定领域并具有有限表达特性的计算机编程语言。”

书中使用格兰特小姐的控制器（Miss Grant's Controller）这种领域特定语言作为例子。这种语言可以用类似打开一个抽屉或者关上一扇门之类的动作来操作建筑物中的密室。通过使用领域特定语言，工程师可以轻而易举地对整个系统进行重新配置，从而避免在通用编程语言编写的配置系统中需要不断识别并在多个位置之间切换的问题。

本书介绍的领域特定语言的类型，不同于主流编程语言所惯有的外部领域特定语言，也不同于诸如 Ruby on Rails 这种基于某种编程语言的内部领域特定语言。本书中介绍了第三种类型，语言工作台，它代表的是一种可以编辑和创造领域特定语言的可定制环境。无论开发人员使用哪一种类型的领域特定语言，作者在书中始终强调的关键是一定要在一种合理的语义模型基础之上打造领域特定语言。

本书不仅仅介绍了领域特定语言的基本概念，同时也尝试用务实的态度和 Java、C#等编程语言的例子对这一主题进行阐释。书中还介绍了一些用于设计领域特定语言的模式以及最佳实践。

InfoQ 有幸采访到 Martin 先生 (MF) 和 Rebecca 女士 (RJP)，以了解他们为这个热门话题写这本书的目的和前因后果：

InfoQ：你们希望通过此书向读者传递的主要信息是什么？

RJP：目前大众对领域特定语言及其用途，实现领域特定语言的相关工具和技术都缺乏了解。通过此书我们试图减轻人们对于创造一种语言所具有的恐惧，带着这个目的，我们希望能够逐渐发现一些有趣并高效的领域特定语言的新用法。

MF：我曾经在一些客户那里看到过不少使用领域特定语言的项目，不过我认为由于很难找到关于打造领域特定语言的各种技术方案和相关信息，他们实际上错过了一些很好的想法。我希望通过这本书把相关的技术收集起来，以便于大家研究领域特定语言。这样我们将更可能看到这项技术的真正潜力在哪里。

InfoQ：模型驱动开发（MDSD, Model-Driven Software Development）和领域特定语言之间的区别在什么地方呢？

MF：这个问题很难回答。我对模型驱动开发社区关注不多，不过看起来这种技术内部似乎已经发展出了一些彼此差别很大的分支。其中有一些着重于通过定义良好的语义模型来驱动计算。对于这一类技术，因为领域特定语言是一种可以较好地描述其备选计算模型的技术，所以它们之间可以很好的协作（本书中我称之为适应性模型 (Adaptive Models)）。

不过模型驱动开发还有另外一种类别，它认为流程图的作用堪比成千上万行代码。这是 CASE 思想的延续，并且和 OMG 的模型驱动架构（MDA）有着千丝万缕的联系。他们对领域特定语言的拥抱只能算是徒劳无功的垂死挣扎了。

InfoQ：领域特定语言能带来哪些好处，什么时候应该选择内部而不是外部领域特定语言？

MF：无论什么时候，如果要讨论领域特定语言的优缺点，我都要强调每一个领域特定语言只是在某个开发库或者框架之上的一层薄薄的皮而已（我们称之为语义模型）。想决定是否需要开发一个领域特定语言，我们只要考虑通过领域特定语言来表达业务行为所带来的好处是不是超过调用普通的命令 - 查询式的 API。

RJP：使用某个能够正确抽象当前问题领域的编程语言能够极大地提高软件开发的效率。同样，根据当前问题领域对一个编程语言进行裁剪也可以提供一个让业务团队更好理解开发团队进展的机制。领域特定语言也可以对自身进行裁剪以适应当前的问题领域，从而有助于增进业务团队和开发团队之间的沟通。

内部和外部领域特定语言其实各有所长。从语言设计的角度来看，外部领域特定语言能够提供最大程度的灵活性，因为内部领域特定语言语言必须遵循宿主语言的解析和语言语义。

MF： 当你和非程序员一起工作时，这种灵活性将会特别有益。

RJP：但是要得到这种灵活性就不得不付出增加开发和构建复杂程度的代价。在开发环境中使用外部领域特定语言需要额外的开发工具。同时，在构建过程中处理外部领域特定语言也需要为其增加专门构建词法分析器的步骤。

MF：词法分析技术是建造外部领域特定语言的关键所在，但是大多数开发者对其并不十分熟悉。在大学中，开发者完全以通用编程语言为背景学习词法分析技术，这让建造外部领域特定语言变得更加困难。

RJP：还有一个需要考虑的问题是，用领域特定语言编写程序所需要的编辑器。对内部领域特定语言来说只要使用宿主语言相同的集成开发环境就可以了，而对外部领域特定语言来说则没有现成的编辑器可用，很可能需要自己写一个。不过考虑到用领域特定语言写的程序大多很短，这也不算是个大问题。然而，对某些类似于分析退休金规则这样的特殊应用程序来说，程序很可能会很长。

InfoQ：一个编程语言需要具备哪些功能和特性才能够易于和领域特定语言相集成？

RJP：这个问题很容易引起对编程语言的语法必须符合某些新语义的争论。实际上领域特定语言可以通过多种形式实现。Lisp 语言有非常灵活的语法并借助了宏处理（macro-processing）功能。Ruby 则包含一种缺失方法（missing method）处理机制。

MF： 我认为闭包（也就是匿名方法或者 lambdas）特别重要，因为闭包允许你控制嵌套表达式的计算顺序，同时也能够非常自然地描述一个分层结构。

RJP： 编程语言的语法越简洁，其生成的领域特定语言也就越简洁。类似 Java 语言中的 "{}" 这种语法元素将使生成的领域特定语言显得杂乱。

InfoQ：我觉得领域特定语言既可以表达问题域也能表达解决方案域。那么它们是否也适用于横切关注点呢？AspectJ 是否也是一种领域特定语言？

MF： 我认为 AOP 是一个完全不同的概念，不过通常认为借助领域特定语言来描述横切问题应该比用普通框架的命令 - 查询式接口更具可读性。

InfoQ：在一个项目组中，您认为哪些角色对于实施领域特定语言负有主要责任，是架构师，开发人员，还是需求分析工程师？系统化实施领域特定语言的流程大致是什么样的？

RJP：这在很大程度上要视领域特定语言的目标用户而定。有些领域特定语言面向的是商务用户，而有些则更多为技术人员设计。关注于商业用户的领域特定语言主要由业务分析师主导语言设计，并和技术团队密切合作。

MF：  我想目前为止我们还没有就在大范围内开发领域特定语言积累足够的经验。

InfoQ：也许大多数领域特定语言不会以一种类似于宇宙大爆炸的方式被一下子创造出来，而是需要慢慢演进？如果是这样：这种演进对软件工程师就其职责和工作内容方面来说会带来哪些潜在影响？我们应该怎样测试领域特定语言？

RJP：谈到测试，根据实现方式不同，测试领域特定语言的方法会有许多不同之处。首先，需要对”语法“进行测试以保证预期的合法语句能够被正确识别。解析器需要的测试工作不多，不过测试一下一个解析过的语句是否符合预期的”语义“还是很有必要。如果你使用书中提倡的语义模型（Semantic Model）方法，语义测试只需确保模型是通过正确的方式生成即可，这其实和传统的通过单元测试验证框架的行为非常相似。

领域特定语言的演进和代码的演进其实如出一辙，唯一的例外是一旦要在生产中开始使用领域特定语言，那么就必须考虑如何把已有的代码移植过去。

MF：领域特定语言程序就像是已有应用程序接口的用户，所以其它 API 在移植中会碰到的问题领域特定语言也会有。当然，我相信演进式设计是最适合领域特定语言发展的。

总体来说，我不认为领域特定语言会对项目中各个角色有很大的影响。领域特定语言更多的只是一种帮助不同角色之间进行更深入和更精确沟通的工具。

InfoQ: 面对某个领域的多种变化，我们应该怎样利用领域特定语言，比方说在开发某个产品线的时候？

MF：和其它许多事情一样，我不认为领域特定语言的代码和其它代码有多大的区别。领域特定语言能够表达人们更深层次的思想是因为，和普通的命令 - 查询式 API 相比，领域特定语言以一种更加自然的方式表述领域内的不同变化。

InfoQ：领域特定语言看起来很擅长解决某个系统内的子域问题，比如说系统配置管理。项目组该如何在创造一种能够覆盖多个领域的复杂庞大的领域特定语言和多个小领域特定语言之间做出取舍？

RJP：领域特定语言的目的是增进理解。通常来说使用过多的领域特定语言可能会阻碍沟通和理解，不过如果每一种领域特定语言都能够非常精确地描述其问题域，使用它们并不会比了解各个问题域更困难。

MF：我们其实非常鼓励使用许多小的领域特定语言。比方说你不会试图去扩展正则表达式来设计 HTML 页面，也不会用 CSS 来进行文本匹配。对我们来说，让领域特定语言与众不同的正是其有限表达这一特性。

InfoQ: 在书中你们专门用一章描述了语言工作台，其中你们提到当前大多数集成开发环境都还不成熟。那么语言工作台到底是什么样子的，它能替代 ANTLR 或者编译器生成程序（compiler-generators）吗？你们对 MPS（Meta Programming System）这类工具的看法如何？

MF：我们一直关注着语言工作台的发展。过去几年间，很多大学一直在这一领域进行国际化的合作研究。这种工具的发展远景很诱人，对开发者来说这种工具将会带来很大的变化，不过目前为止这些工具还不够成熟。简单工具的优点是，它们都基于许多已经被普遍接受的技术之上。不过这种情况会随着语言工作台的快速成熟而改变。

InfoQ：一些组织和项目不接受领域特定语言的主要原因是什么？是因为复杂性，还是因为缺乏对问题域和解决方案域的了解？

RJP：除了新的工具和开发流程这些问题，使用领域特定语言还需要用新的思维方式思考问题。关于哪些是构成好的领域特定语言设计的因素，还有待于我们去逐步发掘。当然也少不了“我们很久以前就听说过”的关于业务可读 / 可写程序的观点以及它所引发的怀疑。

InfoQ：这本书的封面是一座很漂亮的小桥。为什么会选择这幅照片作为本书的封面呢？

MF：当我开始写签名系列时，就决定用桥梁做为封面的主题，这是因为我的太太是一位桥梁工程师。这张照片里的桥很有历史意义，因为它是世界上第一座完全用钢铁建造的桥梁。而且它离我长大的地方不远，所以很早我就基本确定用它作为我下一本书的封面了。

查看英文原文： Book on Leveraging Domain-Specific Languages by Martin Fowler with Rebecca Parsons

感谢侯伯薇对本文的审校。

给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。