视点ViewPoints
一个软件系统通常情况下只用一个符号是不可能描述他所有的方面的, 此外,为了开发流程的需要,不同的方面,在不同的时间里,会被不同的角色描述,因为你要保证有一个干净的概念分离.因此,最重要的是找出描述一个系统不同概念的这些视点,为他们单独提供表现符号和抽象.
在一些系统中意味着你要为不同的关注点定义单独的DSL, 另外的情况下,你可以为一个DSL语义定义一些片断,每一个对应一个视点.
无论你的工具支持哪个方法, 视点需要能够联系到另外的描述整个系统的视点,确保这些”连接点”是显示定义的,并且有数量限制, 另外,要确保这些视点之间依赖的方向是明确的--强烈建议使用单向依赖进行严格分层.
注意这和软件系统的模板化很类似的, 相同的规则应用,强制的内部一致性,少量的外部接口,尽量少的耦合.
分区Partitioning
和软件其它部分一样,DSL编辑器和模型处理器不能够随意扩张,在你从一个小规模的原型开始一个项目的时候往往会忘记这点.在大多数情况下, 我们可以把整个模型划分为单独的”模型单元”.
分区会影响到很多方面,分区可以作为 签入/签出或者锁定的单位, 另外,经常直接引用一个分区,也可以通过代理实现跨分区引用,(工具强制)名称引用或者延迟加载. 分区在本地的限制是经常在编辑器里进行实时检查,全局限制是仅仅可能只按需检查, 这可能是全局编译过程的一部分.
当然, 确保每个分区是单独处理是很有意义的,否则, 可能就需要明确区分哪些分区应该在在给定的处理运行的时候处理(至少可以通过查询路径,目录结构能够找到需要处理的分区,就象C编译器里的include路径一样). 你甚至需要考虑一个单独的编译步骤来合并多种分区的单独处理过程中的结果(就象C编译器,把每个文件都单独的编译成一个目标.obj文件,然后通过symbol/reference进行全局链接).
在很多工具里,分区并不是完全透明的.你可能必须明确的分区,或者你必须确保你不会意外地创建对于其它分区的依赖.因此,最好在DSL和生成器开发过程中就考虑到分区,能够相应地设计元数据.
可行的分区策略设计是语言设计的一部分!记住在这个背景中:哪个分区改变会导致模型的特性变化(比如元素名称改变会导致改变所有其它分区中通过名称引用这个元素地方发生改变), 在哪里存储链接(经常保存在模型中的逻辑指向另外一个的地方吗?),如果不是这样,如何/在哪/什么时候 来控制引用和链接存储.
分区是真正地物理的分割整个模型,它可以与逻辑模型结构或者视点结合起来(比如命名空间),也可以不结合.比如一个描述计费子系统的分区可能包含嵌在多个命名空间中的元素,覆盖多个视点(数据结构,流程,UI定义).
演变 Evolution 
在开始一个MD*项目时容易被忘记的重要一点就是语言演化的必要性。如果你改变语言，确信你已经有办法调整模型处理器和已经存在的的模型。
这需要以下列出来的一个或多个：严格的配置管理控制，模型中的版本信息用来触发兼容的模型处理器，多层模型处理的撤销，能够把基于老语言的模型转换基于新语言的模型的模型迁移工具。
模型迁移是否容易很大程度上取决于工具, 有些工具能够使模型非常平滑地演变,但是有些环境并不是这样.在决定使用哪个工具的时候一定要考虑到这点. 注意如果是文本DSL, 模型迁移至少可以通过正则表达式和grep来完成。
一定要尽量减少对现有模型进行的改动，向后兼容和折旧是在MD*领域值得铭记的两个技术，你可以用你的模型处理器来收集有多少被弃用的语言特征仍然在使用，到模型中看不到有使用的时候，你就可以安全地把这个废弃的语言特征给移除了。
完美隔离多个视点的DSL，防止一个DSL的一些地方修改时，引起所有模型的连带影响。
通用语言的谬误 
预定义的通用语言和生成器都是都是诱人的--尤其是如果你想描述你的系统的技术方面。毕竟你可以使用UML模型一切，其实只是添加了一堆原型和标记值。
应该小心地是，使用预定义语言会使你花费大多数时间在思考如果把你的领域概念硬装进现有的语言。同时，你还不得不考虑到现有语言的抽象和符号。当然，一些通用语言提供了适配功能，比如UML的Profile。至于在现在的实用工具里面，UML还是一直很受欢迎的。你必须添加一些限制来防止用户在你的领域模型里使用一些没有意义的UML功能.不过，你的语言经常会比较像UML,定制的UML工具的实际实用性是远远不够的（注意：符号！符号！符号).最后，你的模型处理器必须处理大而复杂的UML元数据－－Profile经常添加，并且从不删除任何东西。
在实践中，在大多数情况下，最好是定义你自己的DSL, 最初他可能需要多一点工作量，但是不久他就会变得更有效率。
但是，确认你没有重新发明轮子。比如，没有必要重新彻底改造状态图和时序图，UML在这方面已经相当不错了。不过，对于一个有用的UML符号有小的改变，Profile机制是不错的选择。
所以，如果已经有比较合适的通用语言了，直接使用存在的语言，尽量确保你自己的实现是兼容的(duck modeling:如果它看起来象状态机并且具有状态机一样的行为，那么就是一个状态机1).
学习3GLs
上面我们讨论了一个事实，那就是DSL不是一个变相的通用语言。然后，DSL仍然可以学习现有的形式和语言。
这里有四个例子:
1.许多语言需要某种范围的概念： 对于模型元素上的一个给定的引用， 只有类型兼容的模型元素的一个子集构成了这个引用有效的目标。
2.特性不仅可以应用在面象对象里的类上，同样适用于状态机，或者保险合同规范。
3.命名空间的概念在许多DSL里出现，用来组织模型元素的命名方案.
4.许多DSL有实例的概念，能够表达一些概念是其它概念的一个实例，有效地引用内置语言类型系统，作为你的约束检查的一部分，你可能需要做类型计算和类型检查。
要成为一个优秀的DSL设计者，有比较广泛的现有编程语言范式的知识是很有用的，请读这本书《Concepts, Techniques and Models of Computer Programming》。
原文: http://www.jot.fm/issues/issue_2009_09/column6/index.html
由于篇幅太长，所以分几部分翻译。翻译水平有限，如果英语不错，最好直接阅读原文.
向模型驱动开发的同学们强烈推荐此文!
作者：孤独侠客（似水流年）
出处：http://lonely7345.cnblogs.com/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。