领域语言
2001年春天，我供职的Anshinsoft公司开始涉足企业应用开发业务，客户是一家在亚太区数一数二的证券中介和资产管理企业。这段经历激起了我对一个专门的问题领域进行建模，然后将模型转换成软件的兴趣。于是我开始了一段考验毅力的学习旅程，仔细参详了EricEvans的领域驱动设计著作（Domain-Driven Design: Tackling Complexity in theHeart of Software），聆听了Josh Bloch关于如何设计优秀API的教诲（How to Design a Good API & Why it Matters， 以及Martin Fowler关于DSL的教义。
精心设计的DSL旨在向目标用户提供人性化的界面，而做到这一点的最佳途径是让编程模型使用领域专用语言来“说话”。我们一直以来总是把程序设计得像个“黑盒”，很少让业务人员得知其内部细节，这种做法可以休矣。经验告诉我，所有用户都希望查看一下你建模在代码里的业务规则，而不是白板上杂乱的框框和箭头。
嵌在代码里的规则要容易被用户理解，用户必须能看懂你使用的语言，这就是我从事十年领域建模的领悟。当规则可被理解的时候，DSL也就呼之欲出了。随之得到改善的不仅有开发团队和业务人员的沟通效率，还有软件面向用户的表达能力。
对于我们能否为用户提供表现力充沛的语法和语义，实现语言无论何时都是一个决定性的因素。有赖于当今生态环境的巨大发展，我们所设计的语言得以在表现力上有了长足进步。以鼓励开发者编写精炼而富有表现力的代码而论，Ruby、Groovy、Scala和Clojure是先行的表率。在这几种语言下的第一手编程经验让我感觉到，它们的语言风格和表达习惯远比大多数前代语言更适合领域建模。
写这样一本关于DSL的书是很大的挑战。我试图关注DSL的一切现实事物，所以从一开始就设定了具体的领域。当我们渐次展开论述，领域模型随着各种业务需求的累加而变得越来越复杂。这正好充分体现了DSL驱动的开发方式对问题域复杂度增长的适应能力。DSL方式并不是对API设计的颠覆，它只是鼓励你在API的设计思路上多考虑一个维度。请务必记住，你的用户才是DSL的使用者。凡事多从用户的角度去考虑，你一定会成功的！
最后，我想说，DSL并不是银弹。它只是一种工具，你需要在业务需求和技术实现之间找到平衡点。如果你在设计DSL时没有考虑到用户的需求，那么你最终可能陷入“过度设计”的陷阱。如果你在实现DSL时没有考虑到业务规则的复杂性，那么你最终可能陷入“过度实现”的陷阱。在这两者之间，你需要找到最佳平衡点。