领域专用语言 (DSL) 迷思

所谓领域专用语言（Domain Specific Language/DSL），其基本思想是“求专不求全”，不像通用目的语言那样目标范围涵盖一切软件问题，而是专门针对某一特定问题的计算机语言。DSL 之于程序员正如伽南地之于以色列人，是最初也是最终的梦想。几乎自计算机发明伊始，人们就开始谈论 DSL 使用 DSL 了。而前几年随着被誉为“Web 开发领域专用语言”的 Ruby on Rails 迅速走红，DSL 又一次成为人们讨论的热点话题。很多人都认为，DSL 将会是软件业的“next big thing”。然而随着 DSL 的日益流行，围绕着 DSL 出现了很多质疑和误解，比如下面这几个：

DSL 的目标受众是非程序员，业务员或者最终用户

在很多人的心中，DSL 等同于“非程序员的编程语言”(programminglanguage for non-programmers)，因此 DSL 的最终受众应该是非程序员，一切不直接被最终用户使用的 DSL 都不是真正的 DSL，仅仅是另一种使代码看起来不像代码的无聊技巧。

这是一个很有趣的观点，事实上在计算编程语言发展的历史上，的的确确出现过“非程序员的编程语言”，而且还非常有名，它们就是 FORTRAN、COBOL 等这些第一代高级语言。在当时的那个时代，计算机的主要目的是科学计算，而程序员则是专指那些摆弄开关、继电器、纸带以及汇编语言的 geek 们。而计算机的主要非程序员受益者——也就是那些学者和研究员——不得不委托这些人帮助它们完成从数学公式到机器指令的转换。于是第一代高级语言的主要目的是缩短计算公式和可执行的代码之间的差距（比如 Fortran），或者是简化信息管理员的日常工作（比如 COBOL）。有趣的是，恰恰是这些当年的“非程序员”把软件开发发展成了一门正当且颇为体面的职业。

其实当年的“非程序员的编程语言”与今日的 DSL 境况颇为相似，所不同的是，当代企业级信息系统更为复杂，所关注的焦点逐渐从计算转移到数据上，业务领域和计算机的物理过程也不再具有简单直接的对应关系了。而且随着社会分工细化，就算是通过 DSL，我们仍然不太可能把那些衣冠楚楚的 HR 们、销售们和部门经理们统统拉下水变成新新程序员。

我仍然要承认，以最终用户为目标受众的 DSL 是一个很引人侧目且很有意思的主意，但是在相当长的一段时间内都是不太现实的。或许我们需要新的方法（比如精益）来协调 IT 部门和业务部门，或许我们需要全新的软件工程理论，或者某些非常具有独创性的工作方式。谁知道呢，预言未来总是吃力而不讨好的，但我觉得在目前情况下，简单把 DSL 的受众限制在非程序员，业务员或最终用户上，是值得商榷的。

DSL = 整洁的代码

这种观点与前面的观点正好相反，把 DSL 完全当作程序员的游戏，把一切能将代码写得整齐好看的技巧都归结为 DSL。

虽然从形式上看 DSL 和“整洁的代码”都具有简洁清晰的特征，但并不能因此将简单将两者草率地归为等同。从概念上说，程序的编写过程就是把业务领域中的问题通过代码或者程序模型表达出来：

由于计算机的程序模型较为单一（归根结底都是运算和存储），就算是在面向对象技术成为主流的今天，通常情况下，计算机程序不太可能做到与业务领域中的概念一致，或者具有某些直觉的对应。也这正是因为这样，软件的修改和可维护性并没有想象中的容易。我们必须不断地将业务领域中的概念转换成相应的代码模型，然后再进行修改。这种间接性直接造成了软件的复杂度。

而 DSL 的主要目的就是要消除这样的复杂度（或者说，以构造 DSL 的复杂度代替这种复杂度），DSL 就要是要以贴近业务领域的方式来构造软件。因此，DSL 的简洁性往往是一种思维上的简洁性，使我们不用费太多的气力就能看懂代码所对应的业务含义。

从这里我们可以看出 DSL 和“整洁的代码”的根本不同，“整洁的代码”只是泛泛地要求代码简洁易懂，而不太在意是否贴近业务领域。比如对于一个 J2EE 开发者来说，DAO、DTO、FormBean 和 Action 已经足够清晰了，但是这却跟 DSL 沾不上一丝的关联。DSL 更注重强调使用业务词汇，尽可能贴近业务模型来编写代码，使业务模型和程序模型之间具有简洁的对应关系。

因此我们不能将 DSL 等同于“整洁的代码”，只能说 DSL 是一种“整洁的代码”而已。

DSL 必须以文本代码的形式出现

Domain Specified Language，顾名思义，是一种语言，因此 DSL 一定是文本代码形式出现的，不是通过文本代码描述的就不是 DSL。

我们之所以偏爱使用文本代码，主要是由于文本代码易于修改且修改效率极高。多年来软件工程实践表明文本代码是最有效率的编辑形式。但是对于 DSL，问题则有些不同。

正如我们前文所说过的，DSL 首要的目的，是使程序尽可能地接近业务领域中的问题，从而消除不必要的间接性和复杂性。对于大多数业务领域而言，文本代码的形式一经足够好了，我们可以很容易通过特定格式的文本，描述业务领域中的问题。然后也确实存在着一些较为特殊的领域，在这些领域中，文本代码并不是最佳的表现形式。为了更好的贴近业务领域中的概念，我们可能会选择使用一些图形化的 DSL。比如时下颇为流行的一个 DSM（Domain Specific Modeling）工具 GEMS（Generic Eclipse Modeling System）中就大量地使用了不同的图形化的 DSL 来表述系统的各个不同侧面。所以我们并不能简单的把 DSL 局限在文本形式上面。

DSL 的语法应该尽可能地接近英语或者其他自然语言

由于大多数 DSL 是描述性的，因此我们应该尽可能地让 DSL 接近日常使用的英语或者其他自然语言，这样可以增强 DSL 的表现能力。

业务自然语言（Business Nature Language）是 DSL 的一个重要分支。它的产生是基于这样的一些事实：对于大多数企业应用而言，使用一些类似自然语言的语法和结构构造 DSL 是不错的选择；通过业务自然语言，可以推动和促进业务人员和程序员之间的沟通；类自然语言的 DSL 相较其他形式的 DSL 重用起来较为容易。正是由于上述这些特点，BNL 类 DSL 在 DSL 的实践中是最流行的。我个人就曾在三个不同的项目里实现了针对不同领域的 BNL 类 DSL，我甚至在 Smalltalk 语法的基础上修改提炼，得到了一种具有通用语法表达的脚本语言。利用它可以方便地构造 DSL。

虽然 BNL 是我实践得最多也是最为喜爱的一种 DSL 形式，通过前文的分析，我们仍然不能把它当作唯一的 DSL 形式。我们必须时刻谨记，DSL 的首要目的，是使程序尽可能地接近业务领域中的问题，从而消除不必要的间接性和复杂性。合理且恰当地选择语法形式永远是构造 DSL 的重中之重。

作者简介：徐昊，ThoughtWorks 咨询师和敏捷过程教练； BJUG （Beijing Java User Group）和 AgileChina 主要创始人之一；RSSer（Ruby，Smalltalk & Scheme）。目前主要致力于研究编译理论和推广 DSL（Domain Specified Language）在实际项目中的应用。他的博客地址是： http://www.blogjava.net/raimundox 。