DSL编程：有人将DSL编程称之为声明式（Declarative）编程。
DSL是在模型之上建立的一种更加灵活的对 模型化的理解和使用方式。
语义模型是DSL的核心。
内部DSL：用通用语言的语法表示DSL，需要安装某种风格使用这种语言。
外部DSL：在主程序设计语言之外，用一种单独的语言表示领域专有语言。可以是定制语法，或者遵循另外一种语法，如XML。
DSL定义：针对某一领域，具有受限表达性的一种计算机程序设计语言。
外部DSL：不同于应用系统主要使用语言（c，java，c++，c#）的语言。
内部DSL：通用语言的特定用法。内部DSL通常是一段合法的程序，但是具有特定的风格。而且只用到了语言一部分特性。Ruby形成了显著的DSL文化。后面好好看看。
http://blog.csdn.net/chgaowei/article/details/21296483
MDSF：DSL（Domain Specific Language）介绍
前面介绍过模型驱动开发（MDD）、软件工厂（Software factory）、特定领域建模 DSM（Domain Specific）等都是高抽象的开发方法，这些方法使用的语言都是特定领域语言（DSL）。相比于通用目的语言(C#/C++/JAVA/Delphi等）而言，DSL是一种为了特定任务而设计的开发语言，例如SQL是一种专门处理数据库的语言，本篇将介绍一下DSL。
一种语言
我们熟知的编程语言（如C#、Ruby等）是一种通用语言，MDA基于UML语言，而模型驱动开发（MDD）基于DSL。DSL是一种基于特定领域的语言，它使工作更贴近于客户的理解，而不是实现本身，这样有利于开发过程中，所有参与人员使用同一种语言进行交流。
DSML
DSML是 特定领域模型语言（domain-specific modelling language），之前介绍的MetaEdit+使用的DSM方法中使用的就是DSML，它是一种可以用来构建图形模型的一种DSL，DSM的GOPPRR就是一个用来构建DSML语言的元模型。
DSL涉及内容
- 问题域、问题空间
- 语法、语义
- 案例、方法、工具
DSL架构
- DSL脚本（DSL Script）：每一个DSL的核心都是一个域模型，它定义了这一语言所代表的各种概念，这些概念的属性，以及它们之间的关系
- 在问题域中用于构建、配置或者其他用途的一种语言
- 可以是文本，也可以是图形，或者两者混合使用
- 图形语言不只是图表，否则使用Visio之类的画图软件就行了，它实际上是要创建模型，这个模型要能够从概念上描绘你正在创建的系统，并对其内容进行图表化的表示。一个模型可以同时由多个图表来表示，每个图表表示模型的某个方面
- 文本语言用户输入，可以快速的打字。
- 文本语言的优势在于可以进行比较和合并，而图形表达式可以更容易的看出内容之间的关联。
- 相对来说，文本语言比图形复杂
- 语义模型（Semantic Model）
- DSL脚本的一种内存完整表示
- 有时候这个就是抽象语法树（AST）
- 分离Parse和Generate
- 生成代码（Generated Code）:DSL的一个最重要的应用是用来生产简单的文本形式的工件，例如源代码、数据库脚本
- DSL脚本的一种可执行表示
- 解释语义模型
DSL应用的优点
- 高级别的重用：如果仅适用通用编程语言，则每次只能解决一个问题，但如果应用特定领域开发方法设计并实现一些特殊语言，每个特殊语言可以高效地解决一类相似的问题
- 使用DSL的软件架构可以跨接软件工程过程各阶段之间的鸿沟，特别是通过代码生成可以很好的进行设计和实现阶段的衔接
- 让领域专家参与开发过程，不仅仅是需求阶段，架构阶段也需要参与
- 通过在问题空间工作，可以让不熟悉如何实现技术的人，包括商业人士，也能够更了解模型
- 使用DSL表达的模型，可以在问题空间这个较高的抽象层次进行验证，这意味着可以在开发周期的更早期发现因为理解和表述而造成的错误。
- 一个模型中具备了重要的业务知识，将解决方案从一种技术迁移到另一种技术，或在同一技术的不同版本之间迁移，就变的相对容易。一般通过适当修改生成器或解释器就可以做到。
样式（Styles）
之前在信息系统开发平台OpenExpressApp: 之 如何实现自动化测试框架介绍了在OEA上使用Ruby语法实现的一个自动化测试语言，这个就属于内部DSL。而在OpenExpressApp对建模支持的初步计划中介绍的MetaModelEngie属于外部DSL。
外部DSL可以摆脱内部DSL寄宿语言的限制，可以重新设计一种新的语言，但是增加了学习新的语言的学习成本，并且需要工具的支持。
设计DSL
为了降低风险，我们并不是马上就从头开始开发框架及其DSL，而是应该从现有的可以在某些应用中使用的代码开始，逐步的对其进行参数化，逐步的发现那些在不同应用中变化的部分，然后使这些部分依赖于DSL。
自上而下的方法倾向于快速建立一个完整且自包含的模型，具有更长远的考虑，有助于保证结构的一致性。但是从另一方面看，这种方法容易导致在概念层设计出很复杂的模型，并且该模型难于实现。因此在实际应用中，将自上而下和自下而上两种方法交替使用会更有效。采用渐进的方式可以避免早期投入过大风险，但是需要定期进行一致性检查。
在《Visual Studio DSL工具特定领域开发指南》书中对设计DSL做了如下步骤：
- 识别可变性与发现DSL：DSL是用你的框架具体的实现你的体系架构模式中可变的部分
- 开发领域模型捕获可变性
- 定义标记：在适当的地方使用常见标记法或与标记法相关的约定
- 开发验证的约束：识别树形之间的依赖性，认出快照中的强制或禁止的循环
- 开发并演进框架：理解你的DSL针对的代码体系结构，并在框架中编写它
- 测试DSL：包括验证的约束与规则、生成器与命令、以及生成的代码
- 演化和移植DSL：确保旧的模型在新版本的DSL中能够使用
- 识别好的DSL：范围、最小性、常见标记法，适度的冗余，合理的使用句法空间，使用用户术语
应用场景
......
书籍
Martin Fowler花了几年时间写了一本DSL的书籍《Domain Specific Languages》，我还没有看，感兴趣的可以先看看它在网站上写的系列文章 Domain Specific Languages
Best Practices for DSLs and Model-Driven Development
读书笔记：Visual Studio DSL工具特定领域开发指南
DSL的演进
http://www.educity.cn/wenda/130355.html
