这篇笔记的内容来自MF http://martinfowler.com/dslwip/UsingDsls.html
领域特殊语言(Domain Specific Language)定义
a computer programming language of limited expressiveness focused on a particular domain.
关注特定领域表述有限的计算机程序语言
四个重要元素
- computer programming language:A DSL is used to humans to instruct a computer to do something, as well as helping communication between humans.
计算机语言 DSL帮助用户与计算机交互，同时辅助人与人的交流。 - language nature: A DSL is a programming language, and as such should have a sense of fluency where the expressiveness comes not just from individual expressions but also the way they can by composed together.
语言属性 DSL是一个程序语言，拥有流畅的表述形式，且能够组合完成逻辑。 - limited expressiveness: a general purpose programming language provides lots of capabilities, supporting varied data, control, and abstraction structures. All of this is useful but makes it harder to learn and use. A DSL supports a bare minimum of features needed to support its domain. You can’t build an entire software system in a DSL, rather you use a DSL for one particular aspect of a system.
有限的表述 与通用语言相比，DSL应当只对针对的领域做有限的支持，因此，不应当用DSL实现一个完整的应用。 - domain focus: a limited language is only useful if it has a clear focus on a limited domain. The domain focus is what makes a limited language worthwhile.
领域关注 当明确针对一个特定领域时，有限语言显得非常有用。
DSLs的边界
DSLs的边界很难明确定义，有些语言和工具，在针对特殊问题是表现了DSL的某种特性，但是他们并不能算做DSLs
If a uses a DSL for its purpose then it stays a DSL, but if someone uses a DSL in a general purpose manner, then it’s no longer a DSL (in this usage).
这种模糊并不关键，只要工具有用就行了，使用DSL的观点设计和使用软件，是否能够给软件工程带来总体上的优越性是我们主要关注的课题。
DSL片段与独立程序
DSL可以是一个独立的程序，构建于整体模型之上；也可以是一段执行片段，比如正则表达式，嵌入程序中的SQL等等。
使用DSL的理由
加快开发效率（Improving Development Productivity）
DSL产生了更加简洁，有效的代码，更好的遵守DRY原则，同时有限的语言也避免了很多程序错误的产生。
促进与领域专家的沟通 （Communication with Domain Experts）
这里不是说一个COBOL式的幻想，我们不主张让领域专家来用DSL编写业务规则，程序就能够运行。不过DSL简洁生动的语法，的确更容易被领域专家阅读和接受，从而缩小业务模型与程序模型之间的差距。
在执行上下文中改变 Change in Execution Context
在执行上下文中改变。从而极大的提高了系统的配置化程度，提升其应用功能价值。
可替换的计算模型 Alternative Computational Model
基于领域模型之上，可以更加灵活的设计计算模型，从而完成业务沉淀。
DSLs存在的问题
- 学习曲线
任何一项技术都是有难度的 - 构建花费
构建DSL要求更加精确，但其花费并不是在DSL，而在构建模型本身。 - 设计难度
DSL很难设计，因为它就像类库一样，因此，这种难度也不是DSL带来的，应当是问题域本身的难度。 - 新的DSL的学习难度
DSL构建出来的语言也是需要学习的，不过这取决于DSL本身的设计。 - DSL版本迁移
API已经有很多重构的工具和方法可以使用，DSL还缺乏这些东西，当然内置式的DSL完全可以用载体语言来实现。
DSLs生命周期
很多不同的方式：
Model –> API –> DSL
DSL –> senarios –> functions
Frameworks –> controllers –> DSL