当DSL（Domain-Specific Languages）诞生时，不少人比较激动，欢呼一个新的语言时代到临。其实，这不是计算机领域的新语言，而是一种新的建模语言。
DSL是一种专门供领域建模专家（也就是系统分析师）使用的语言，这些领域专家不同于程序高手，他们有一套自己认知世界和表达世界的思维和方式（如UML），因此，他们不感兴趣于软件设计细节，希望软件能够按照他们分析设计的结果去运行和执行就可以了。
其实，现如今在Java和.NET分治天下软件语言之时，不可能再有对和Java等同样层次的新语言的新需求， 因为大家都已经经历过优美动人的语言故事，新语言陷阱是每个人理性的认识。因此，聪明的专家发现，DSL特征不是发明新轮子，而是提供一种面向领域建模方便的工具语言，类似UML，但UML不能再胜任这样的工作（见UML和Java的阻抗），MDA有待进一步完善提高，建模专家需要的是DSM（Domain-Specific Modeling）。
提高开发生产效率
按照软件生产效率研究（Software Productivity Research）, Java的平均生产率仅比BASIC高20%, C++不会好过Java，当今Java和.NET语言纷争带给程序员很多选择的痛苦，我们把更多注意力关注在对象、组件和框架（objects, components, and frameworks）等概念上，但是开发效率并没有比20年前有显著增长，从汇编语言到BASIC是400%的增长，在当前21世纪，我们应该怎样完成这样的跳跃式发展？
UML能否胜任？
象UML这样传统的建模语言并不能提高软件生产率，你需要在两处维护信息系统：语言代码和UML模型，为保持一致来回奔命，我们知道，java/C++/BASIC都将被编译器编译成汇编语言，可是有人看到过这样情形：开发者手工更改编译器并且试图使C++代码和汇编代码保持一致？可是这种现象会发生在UML模型和语言代码之间。
当然，UML有其优点：作为能够迅速被读懂的虚拟符号，UML世界现在吵吵嚷嚷，一半人发现UML并不能表达他们在建模时需要的一些概念，因此要求将入一些新的东西进入UML核心标准；可是还有另外一些人则认为UML太复杂，应该从UML核心元素中减去一些元素。当UML试图适合所有的人时，它就不能大力提高其抽象层次了。
这是目前基于UML的大多数MDA工具发生尴尬现象。MDA工具制造商发现它们仅仅能够比手工编码提高生产效率(study)35%，远没有我们希望的400%革命性跳跃。
什么是DSM？
只有提高抽象层次，将软件直接面向建模专家或系统分析师，然后运用自动化代码生成技术，这样才能高质量大幅度快速开发出软件系统，在OOPSLA（领先的软件工程会议），大家认为DSM可能是一种解决方案。Bill Gates 和 Grady Booch也发表过同样观点。
DSM意味Domain-Specific Modeling领域定义建模，通过使用领域概念直接指定解决方案，DSM提高了超越程序代码之上的抽象层次，最终软件产品将从高层次的设计中直接自动产生，这样一个自动过程是可以实现的，因为 语言和代码产生器可以满足某一个公司或领域的需求，建模专家使用定义这个自动机器，而程序员只管使用即可。
实践经验已经证明：DSM比现有方式（包括基于UML的MDA）效率提高5-10倍，正如Booch说的那样： ”当建模概念可以直接映射到领域Domain，而不是计算机具体技术概念时，MDA的价值已经完成“，这句话的意思是： MDA已经证明我们可以直接从领域专家Domain观点直接建模，而不必拘束于具体的计算机技术概念，或者说：直接由有经验的系统分析师/建模专家分析设计进而生产出软件系统已经被MDA证明是可行的了，MDA的价值也就在于此，
Booch等人寄希望于使用DSM替代MDA。
由建模专家定义有关领域和组件的代码产生器，这样做的结果要好于大多数开发者手工开发。从MDA教训来看，大家认识到：不可能有“一种尺寸适合所有身材”的代码产生方案，不必象MDA那样疲于往来返工，DSM所做的正如将代码编译成汇编语言的编译器所做的。
DSM工作原理
首先，每个行业都有一些经验丰富行业专家，俗成系统分析师，他们对业务系统非常熟悉，但是不太了解软件技术，由这些专家定义一个包含域概念和规则的域定义语言（domain-specific language），并且定义这些域概念和规则映射到代码产生器的映射；实际上这些建模专家所要表达的就是：我们的需求应该看上去是怎样？我是怎么写代码的。
然后，其他开发者就使用建模语言根据前面定义的规则制作模型，最后，代码将自动产生，因为建模专家参与了定义代码生产器，这样最后产生的代码质量要高于正常程序员手工完成的代码质量。更重要的是，制作模型将比手工写代码更快。
与MDA区别
DSM与MDA主要区别是：MDA工具商自己定义代码产生器，这些代码产生器第一次看非常好，但是以后就变样走味了，难以适应需求的变化。.
DSM中，由你控制DSL和代码产生器，这些工具可以被调整以适应你自己的系统，作为开发者，你只需要定义DSL和实现自己的代码产生器，所有这一切都是由你来定义控制，正所谓定制性强。
DSL案例
TSS上最近的文章“Improving Developer Productivity with Lightweight Domain Specific Modeling”演示了如何使用DSM实现轻量建模的过程，共分五步：
ArgoUML 能够用作定义DSL模型，开发人员能够设计DSL模型适合问题域。
将 ArgoUML模型转为Eclipse模型格式的Ecore.
使用Eclipse的插件JET模板定义代码如何产生。
Ecore模型输入到模板定义中，然后再定义Ecore模型中的模型元素和带有Merlin的JET模板之间映射。
最后结果是产生最终代码。
参考文章：
Improving Developer Productivity with Lightweight Domain Specific Modeling
Why DSM?
Ruby On Rails 与Jdon Framework架构比较
文章来源于领测软件测试网 https://www.ltesting.net/
