如何设计领域特定语言，实现终极业务抽象？

在过去的几年里，我一直从事于各种领域定义语言的设计，包含 unflow、guarding、datum、forming 等。在我刚入门这个领域的时候，我从《领域特定语言》、《编程语言实现模式》 等，一直研究到龙书等。我渐渐掌握了领域特定语言设计的一些技巧，也能快速(相对于过去)设计出一个领域特定语言。

公司主营业务：成都网站设计、成都做网站、移动网站开发等业务。帮助企业客户真正实现互联网宣传，提高企业的竞争能力。创新互联是一支青春激扬、勤奋敬业、活力青春激扬、勤奋敬业、活力澎湃、和谐高效的团队。公司秉承以“开放、自由、严谨、自律”为核心的企业文化，感谢他们对我们的高要求，感谢他们从不同领域给我们带来的挑战，让我们激情的团队有机会用头脑与智慧不断的给客户带来惊喜。创新互联推出秦都免费做网站回馈大家。

所以，我在想我应该总结一下相关的套路。这样一来，也可以在未来验证现在的思路是否正确：

  1. 定义呈现模式。
  2. 提炼领域特定名词。
  3. 设计关联关系与语法。
  4. 实现语法解析。
  5. 演进语言的设计。

领域特定语言

领域特定语言(英語：domain-specific language、DSL)指的是专注于某个应用程序领域的计算机语言。

本文所写的皆是外部 DSL，即『不同于应用系统主要使用语言』的语言。创建外部 DSL 和创建一种通用目的的编程语言的过程是相似的，它可以是编译型或者解释型的。

通用目的编程语言的源代码和外部 DSL 的源代码之间的主要区别在于，经过编译的 DSL 通常不会直接产生可执行的程序(但是它确实可以)。大多数情况下，外部 DSL 可以转换为一种与核心应用程序的操作环境相兼容的资源，也可以转换为用于构建核心应用的通用目的编程语言。—— Vaughn Vernon

简单场景下的领域特定语言，只是将特定的源码转换为特定的数据结构。如 JSON 便是一种 DSL，在 Java 语言里，需要将它转换为对应的数据类。复杂场景下的领域特定语言，可以直接编译为可执行程序。

外部 DSL 的麻烦点在于：

  • 语法设计
  • 语法解析
  • IDE 支持

当然了，它的优点也很明显：

  1. 让不懂编程的业务专家(领域专家)快速编写核心逻辑。
  2. 领域逻辑与具体编程语言无关
  3. 平台无关。

更多的信息，建议去阅读《领域特定语言》一书。

定义呈现模式

领域特定语言嘛，从需求上就是对于业务呈现的简化。根据不同的呈现模式，去解析源码，得到我们所需要的数据结构。

呈现模式

如下是常见的的领域特定语言的使用模式 [wiki_dsl]：

  • 独立的工具，如 Makefile
  • 在编译时或实时转换为宿主语言
  • 嵌入式领域特定语言
  • ……

可以参见维基百科，我就不再去翻译了。

[wikidsl]: https://en.wikipedia.org/wiki/Domain-specificlanguage

定义数据结构

从通用语言的编译过程来看：

  1. 词法分析器，分析输入的字符流，得到符号流。
  2. 语法分析，分析符号流，得到语法树
  3. 语义分析，分析语法树，得到新的语法树
  4. 中间代码生成器，分析语法树，得到中间表示形式
  5. ……

步骤 1~4，对于通用语言和领域特定语言来说都是极为类似的。唯一拥有区别的是这个中间表示形式，对于领域特定语言来说，我们场景的原因，这里往往是我们所需要的数据结构。

当然了，从某种意义上来说，AST(抽象语法树)也是一种数据结构，只不过它是一种中间的数据结构。所以，有时候在设计的时候，我就偷懒直接输出中间表示了。

提炼领域特定名词

这个环节的过程，实现上和 DDD(领域驱动设计)里的提炼问题域以获取领域知识是颇为相似的。同样的这个过程中，通过与领域专家的协作，我们才能获得更好的领域特定语言。

从用例开始

用例，或译使用案例、用况，是软件工程或系统工程中对系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。

在进行领域驱动设计协作时，我们需要与领域专家理解用户在这个过程中，进行的一系列操作，以提炼我们所需要的统一语言。而其中的用例能描述达到目标所需的步骤，包含用户和系统之间的交互。

在创建领域特定语言的时候，这个过程对于我们来说，也是类似的：与领域专家一起协作，从用例开始提炼。它也可以直接由现有的代码中提炼而来。

从已有用例入手

对于已有系统来说，用例可以由：

与领域专家交流获取。与领域专家聊天，是我们获得用例的最好方式。记录用例，从而获得关键信息。

从现有的代码中提取。

在 ArchUnit 中提取架构规划上的设计便是：

 
 
 
 
      
  
  
  
  1. classes().that().resideInAPackage("..foo..") 
    2.   
  
  
  
  2. .should().onlyHaveDependentClassesThat().resideInAnyPackage("..source.one..", "..f 
    3.

对应的，我们在 Guarding 的设计是：

 
 
 
 
      
  
  
  
  1. class(resideIn "..foo..") dependent package(resideIn ["..source.one..", "..foo.."] 
    2.

在 Guarding 中设计的是针对主流的编程语言，所以在语法上会尽量与编程语言无关。

提取关键字、值、属性

在获得了用例作为输入条件之后，我们就需要从中提取一些关键信息，如关键字、值、属性等等。

如下是我在设计 Guarding DSL 时，从 ArchUnit 提取的一小部分关键信息：

 
 
 
 
      
  
  
  
  1. package: 
    2.   
  
  
  
  2.   dependOn 
    3.   
  
  
  
  3.  
    4.   
  
  
  
  4. class: 
    5.   
  
  
  
  5.   implement 
    6.   
  
  
  
  6.   annotation 
    7.   
  
  
  
  7.   annotatedWith 
    8.   
  
  
  
  8.  
    9.   
  
  
  
  9. expression: 
    10.   
  
  
  
  10.   and 
    11.   
  
  
  
  11.   or 
    12.   
  
  
  
  12.   not 
    13.   
  
  
  
  13.   equals 
    14.   
  
  
  
  14.   only 
    15.

接着，我们就可以依据这些信息，展开它们的关联设计，进而设计我们的语法。

设计关联关系与语法

在设计领域特定语言时，我们主要以实现领域中的用例作为目标：

  1. 使用 DSL 描述一个用例
  2. 先不考虑语法实现，实现大部分用例的 DSL 草稿版本
  3. 对齐不同用例 DSL 中的差异
  4. 考虑一些非常规的用例，添加额外的属性

名词关系与逻辑设计

领域特定语言，所针对的是特定领域。在特定的领域里，都会使用特定的词汇来描述相关之间的关系。这个关系，便是我们设计语法的一个关键。

如在 Java 语言里，使用： implement、 extends 来表示两个类之间的关系。而为了表示包之间的关系，则会有： dependent、 resideIn 等等的关系。

实现用例

实现用例并不是一个复杂的过程，只是要符合人类的思维习惯，并尽可能地简化设计。不过，觉得注意的是，我们应该留下一些证据来告诉未来的自己：我们当时是为什么考虑的。

在设计 DSL 时，我往往会创建一个 sample 文件，以记录过程中，对于不同的要素的思索。如我在设计 Guarding DSL 里，使用了一个 0.0.1.sample 文本文件，来描述早期版本的语法示例：

 
 
 
 
      
  
  
  
  1. # 正则表达式 
    2.   
  
  
  
  2. package(match("^/app")) endsWith "Connection"; 
    3.   
  
  
  
  3.  
    4.   
  
  
  
  4. package("..home..")::name should not contains(matching("")); 
    5.   
  
  
  
  5.  
    6.   
  
  
  
  6. # 简化的比较 
    7.   
  
  
  
  7. class::name.len should < 20; 
    8.

通过一些注释来让自己优化设计。

实现语法解析

这一部分的过程，和我们学习编译原理时基本是一致的。不过呢，在编写领域特定语言的时候，我们一般会使用解析器生成器，而不是手写解析器。

细节设计

设计领域特定语言的时候，在设计语法上的拘束不会像通用语言那么多。所以，自由设计的范围就大一点，有些内容也不一定需要像编程语言麻烦。诸如于：

  • 分隔符
  • 缩进的处理
  • 语法块的开始和结束
  • ……

PS：使用类似于编程语言的写法，对于写 DSL 的非编程人士来说可能会变成一种困扰。

解析器生成器

经典的 Lex & Yacc 是你可以考虑的范围，在不同的语言里也有一些相似的实现。

对于我来说，以下是我常用的一些解析器生成器。

  • Antlr。支持主流的语言
  • Peg.js。JavaScript
  • Pest。Rust
  • Lalrpop。Rust

我还是比较习惯用 Antlr，支持的语言较多。我与同事以及开源社区的小伙伴们，在下面的项目中都使用过 Antlr：

  • Coca = Golang + Antlr
  • Unflow = Rust + Antlr
  • Lemonj = JavaScript/TypeScript + Antlr
  • Chapi = Java/Kotlin + Antlr

从使用上它们之间的差距并不大，但是都需要学习成本。

演进语言的设计

最后，让我们来谈谈一些有意思的东西，虽说是演进吧，但是，和设计暂时没有太大的关系。

测试驱动开发

经我大量发现，TDD 是非常适合于编程语言的开发与设计。需求是未知的，易于发生变化的，还需要覆盖足够全的场景。

从实践的层面上来说，主要是有两种：

  1. 面向语法的测试。即，只让语法编译能通过，但是不报错。
  2. 面向功能的测试。即，验证某一部分的语法是正确的。
  3. 面向用例的测试。即，验证符合使用场景。

自动化语言迁移

原先这部分的标题是，向下兼容。但是，我一直觉得向下兼容不是一个好主意。所以呢，我就想了想把在其它领域的经验搬了过来，于是呢，内容就变成了自动化语言迁移。

在关于版本的迁移上，我觉得 Angular 语言上关于版本的自动化迁移，是值得我们去借鉴的。当然了，采用这种设计的成本非常高，我们需要有一个专门的团队，使用工具自动化分析旧的系统，并使用工具来自动修改旧的代码。

其它

文中相关 DSL 链接(欢迎加入 Inherd 一起编写 DSL)：

Unflow: https://github.com/inherd/unflow

Guarding: https://github.com/inherd/guarding

Forming: https://github.com/inherd/forming

本文转载自微信公众号「phodal」，可以通过以下二维码关注。转载本文请联系phodal公众号。

文章名称：如何设计领域特定语言，实现终极业务抽象？
文章路径：http://www.shufengxianlan.com/qtweb/news26/100826.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联

猜你还喜欢下面的内容

动态网站知识

同城分类信息

成都网站设计　　 　成都网站建设　　 　小谭建站工作室　　 　四川中建建业　　 　成都名片印刷厂　　 　普格博源建站　　 　德信企业管理　　 　成都小程序定制开发公司　　 　达州主机托管　　 　ssl数字证书　　 　亚克力背部发光字　　 　小谭建站　　 　成都网站制作　　 　成都广告设计公司　　 　成都网站制作　　 　广告品牌策划设计　　 　西云服务器托管　　 　铁科精智测控　　 　古蔺网站建设　　 　seo推广公司