哪个是最佳选择
有两种风格的语言设计:一种主张大语言,用一个类支持许多不同的领域概念.另外一种主张小语言,使用一些小但是强大的原始的特征,大一些的特征由库的方式组装构建．
在构建DSL的时候需要一直记住的是：确认你的语言设计始终保持一致．你保持上面两种方法思想中的一个.使用第二个方法会更复杂，并且需要花费比较大的努力发现这些基本的原始特征．尤其对于业务领域DSL,第二种方法基本会失败，因为业务用户并不习惯于使用新的，强大的，正交概念．
用容易确认地，众所周知的概念定位DSL，一定要保证这些概念是最佳的选择，并且使用合适的符号，例如，在移动手机开发的DSL中，确信你的最基本的都是可输入的原子（左键，右键，0..9数字键，操纵杆).不要尝试抽象成通用的”输入设备”.
你也可以组合这两种方法，然而，确认你的语言保持一致性和完整性。
库 Libraries 
前面的最佳实践提到的一个概念就是Libraries的使用。Libraries是你的DSL的一些实例的集合，主要用于重用，一般存储在单独的模型分区中.
Libraries很明显有助于重用模型数据。例如，在一个用于描述数据结构的DSL里,经常就会把一些重用的数据结构放到一个Libraries里提供给其它使用（比如date,time,address，另外Libraries就是分区的一种形式).
Libraries也用于降低语言的复杂性，考虑上面提到的数据结构DSL:代替直接硬编码原始类型int,string,bool,你可以实现一个原始类型构造器生成int,string,bool类型实例。这样也能够允许用户添加直接通过修改模型添加新的原始类型，而不是直接修改语言，这能够减少不少麻烦.
如果你使用library方法，保证模型处理器没有假设更高层次的结构构造，取代的是真正的基于基本的原始特征。在我们的例子里，映射的原始类型对应着目标语言(比如java)，这需要作为模型的一部分，否则当你通过类库添加一个新的原始类型的时候，还需要修改代码生成器。
团队支持
DSL工具很重要的一个方面是支持版本，标签，分支，锁定，比较和合并，协助操作模型的所有方面。确保你使用的工具支持所有这些，使用语言的具体语法，没有人愿意用抽象的 语法/元模型/树 层次来处理这些问题。
当面对业务专家，基于资料库的系统是非常有能力解决这些问题的，然而，当你直接面对开发者时，模型必须与其它的开发工具进行互操作。尤其是你需要与现有的源代码控制系统集成时(CVS,SVN,Gitt等)。再者，如果你的系统是模型特定的或者是手写的3GL代码，必须能够加标记，对两个文件进行比较和版本控制来防止带来灾难.一个明确资料库的工具在这种场景下如果它并不提供集成资料库代码的方法的话,会有比较大的问题.
文本DSL在这方面有明显的优势, 讲到这里为止,模型还只是文本(至少他们存储为文本文件,并且文本符号是潜在的数据存储结构).
就商业用户而言,悲观锁定(没有必要进行比较和合并)可能更容易理解.通常在悲观和乐观方法之间做选择的时候,应该基于处理的过程和收集的用例.
好的分区能够使团队支持更加容易, 分区实际上成为比较,合并,锁的基本单位.
工具细节
定义语言和符号本身是不够的,你还必须为他们提供良好的工具支持.
DSL的编辑需要能够支持团队工作（见上文），导航，全局查看，搜索，快速查找，查找引用，显示被使用处，甚至重构。对于文本的DSL，你的编辑器必须提供代码完成，语法高亮等，以确保发展人员（使用强大的集成开发环境开发”正规”语言的人）愿意使用DSL工作。
对于“元数据开发者”也是一样。请确保您的环境提供好的用户体验, 比如编写转换和代码生成，为这些提供了元模型感知编辑器。
为了提高可用性，DSL的编辑器必须能够应付由用户输入导致的异常或不完整的模型。理想情况下,出现这种情况后,可能还需要持续。不过,只要模型是错误的或不完整，他们无法处理任何进一步。对于文本语言的环境下，这可能意味着你设计一个有点“松散”，更宽容的语法，通过约束来保证执行的正确性。
您还必须确保该模型处理器能够运行在不间断生成（外部的编辑器或工具的一部分）来集成到现有的基础环境中。
[翻译] DSL和模型驱动开发的最佳实践(1/4)
[翻译] DSL和模型驱动开发的最佳实践(2/4)
原文: http://www.jot.fm/issues/issue_2009_09/column6/index.html
由于篇幅太长，所以分几部分翻译。翻译水平有限，如果英语不错，最好直接阅读原文.
向模型驱动开发的同学们强烈推荐此文!
作者：孤独侠客（似水流年）
出处：http://lonely7345.cnblogs.com/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。