如何設計領(lǐng)域特定語言，實現(xiàn)終極業(yè)務抽象？
在過去的幾年里，我一直從事于各種領(lǐng)域定義語言的設計，包含 unflow、guarding、datum、forming 等。在我剛?cè)腴T這個領(lǐng)域的時候，我從《領(lǐng)域特定語言》、《編程語言實現(xiàn)模式》 等，一直研究到龍書等。我漸漸掌握了領(lǐng)域特定語言設計的一些技巧，也能快速(相對于過去)設計出一個領(lǐng)域特定語言。
所以，我在想我應該總結(jié)一下相關(guān)的套路。這樣一來，也可以在未來驗證現(xiàn)在的思路是否正確：
- 定義呈現(xiàn)模式。
- 提煉領(lǐng)域特定名詞。
- 設計關(guān)聯(lián)關(guān)系與語法。
- 實現(xiàn)語法解析。
- 演進語言的設計。
領(lǐng)域特定語言
領(lǐng)域特定語言(英語：domain-specific language、DSL)指的是專注于某個應用程序領(lǐng)域的計算機語言。
本文所寫的皆是外部 DSL，即『不同于應用系統(tǒng)主要使用語言』的語言。創(chuàng)建外部 DSL 和創(chuàng)建一種通用目的的編程語言的過程是相似的，它可以是編譯型或者解釋型的。
通用目的編程語言的源代碼和外部 DSL 的源代碼之間的主要區(qū)別在于，經(jīng)過編譯的 DSL 通常不會直接產(chǎn)生可執(zhí)行的程序(但是它確實可以)。大多數(shù)情況下，外部 DSL 可以轉(zhuǎn)換為一種與核心應用程序的操作環(huán)境相兼容的資源，也可以轉(zhuǎn)換為用于構(gòu)建核心應用的通用目的編程語言。—— Vaughn Vernon
簡單場景下的領(lǐng)域特定語言，只是將特定的源碼轉(zhuǎn)換為特定的數(shù)據(jù)結(jié)構(gòu)。如 JSON 便是一種 DSL，在 Java 語言里，需要將它轉(zhuǎn)換為對應的數(shù)據(jù)類。復雜場景下的領(lǐng)域特定語言，可以直接編譯為可執(zhí)行程序。
外部 DSL 的麻煩點在于：
- 語法設計
- 語法解析
- IDE 支持
當然了，它的優(yōu)點也很明顯：
- 讓不懂編程的業(yè)務專家(領(lǐng)域?qū)＜?快速編寫核心邏輯。
- 領(lǐng)域邏輯與具體編程語言無關(guān)
- 平臺無關(guān)。
更多的信息，建議去閱讀《領(lǐng)域特定語言》一書。
定義呈現(xiàn)模式
領(lǐng)域特定語言嘛，從需求上就是對于業(yè)務呈現(xiàn)的簡化。根據(jù)不同的呈現(xiàn)模式，去解析源碼，得到我們所需要的數(shù)據(jù)結(jié)構(gòu)。
呈現(xiàn)模式
如下是常見的的領(lǐng)域特定語言的使用模式 [wiki_dsl]：
- 獨立的工具，如 Makefile
- 在編譯時或?qū)崟r轉(zhuǎn)換為宿主語言
- 嵌入式領(lǐng)域特定語言
- ……
可以參見維基百科，我就不再去翻譯了。
[wikidsl]: https://en.wikipedia.org/wiki/Domain-specificlanguage
定義數(shù)據(jù)結(jié)構(gòu)
從通用語言的編譯過程來看：
- 詞法分析器，分析輸入的字符流，得到符號流。
- 語法分析，分析符號流，得到語法樹
- 語義分析，分析語法樹，得到新的語法樹
- 中間代碼生成器，分析語法樹，得到中間表示形式
- ……
步驟 1~4，對于通用語言和領(lǐng)域特定語言來說都是極為類似的。唯一擁有區(qū)別的是這個中間表示形式，對于領(lǐng)域特定語言來說，我們場景的原因，這里往往是我們所需要的數(shù)據(jù)結(jié)構(gòu)。
當然了，從某種意義上來說，AST(抽象語法樹)也是一種數(shù)據(jù)結(jié)構(gòu)，只不過它是一種中間的數(shù)據(jù)結(jié)構(gòu)。所以，有時候在設計的時候，我就偷懶直接輸出中間表示了。
提煉領(lǐng)域特定名詞
這個環(huán)節(jié)的過程，實現(xiàn)上和 DDD(領(lǐng)域驅(qū)動設計)里的提煉問題域以獲取領(lǐng)域知識是頗為相似的。同樣的這個過程中，通過與領(lǐng)域?qū)＜业膮f(xié)作，我們才能獲得更好的領(lǐng)域特定語言。
從用例開始
用例，或譯使用案例、用況，是軟件工程或系統(tǒng)工程中對系統(tǒng)如何反應外界請求的描述，是一種通過用戶的使用場景來獲取需求的技術(shù)。
在進行領(lǐng)域驅(qū)動設計協(xié)作時，我們需要與領(lǐng)域?qū)＜依斫庥脩粼谶@個過程中，進行的一系列操作，以提煉我們所需要的統(tǒng)一語言。而其中的用例能描述達到目標所需的步驟，包含用戶和系統(tǒng)之間的交互。
在創(chuàng)建領(lǐng)域特定語言的時候，這個過程對于我們來說，也是類似的：與領(lǐng)域?qū)＜乙黄饏f(xié)作，從用例開始提煉。它也可以直接由現(xiàn)有的代碼中提煉而來。
從已有用例入手
對于已有系統(tǒng)來說，用例可以由：
與領(lǐng)域?qū)＜医涣鳙@取。與領(lǐng)域?qū)＜伊奶欤俏覀儷@得用例的最好方式。記錄用例，從而獲得關(guān)鍵信息。
從現(xiàn)有的代碼中提取。
在 ArchUnit 中提取架構(gòu)規(guī)劃上的設計便是：
- classes().that().resideInAPackage("..foo..")
- .should().onlyHaveDependentClassesThat().resideInAnyPackage("..source.one..", "..f
對應的，我們在 Guarding 的設計是：
- class(resideIn "..foo..") dependent package(resideIn ["..source.one..", "..foo.."]
在 Guarding 中設計的是針對主流的編程語言，所以在語法上會盡量與編程語言無關(guān)。
提取關(guān)鍵字、值、屬性
在獲得了用例作為輸入條件之后，我們就需要從中提取一些關(guān)鍵信息，如關(guān)鍵字、值、屬性等等。
如下是我在設計 Guarding DSL 時，從 ArchUnit 提取的一小部分關(guān)鍵信息：
- package:
- dependOn
- class:
- implement
- annotation
- annotatedWith
- expression:
- and
- or
- not
- equals
- only
接著，我們就可以依據(jù)這些信息，展開它們的關(guān)聯(lián)設計，進而設計我們的語法。
設計關(guān)聯(lián)關(guān)系與語法
在設計領(lǐng)域特定語言時，我們主要以實現(xiàn)領(lǐng)域中的用例作為目標：
- 使用 DSL 描述一個用例
- 先不考慮語法實現(xiàn)，實現(xiàn)大部分用例的 DSL 草稿版本
- 對齊不同用例 DSL 中的差異
- 考慮一些非常規(guī)的用例，添加額外的屬性
名詞關(guān)系與邏輯設計
領(lǐng)域特定語言，所針對的是特定領(lǐng)域。在特定的領(lǐng)域里，都會使用特定的詞匯來描述相關(guān)之間的關(guān)系。這個關(guān)系，便是我們設計語法的一個關(guān)鍵。
如在 Java 語言里，使用： implement、 extends 來表示兩個類之間的關(guān)系。而為了表示包之間的關(guān)系，則會有： dependent、 resideIn 等等的關(guān)系。
實現(xiàn)用例
實現(xiàn)用例并不是一個復雜的過程，只是要符合人類的思維習慣，并盡可能地簡化設計。不過，覺得注意的是，我們應該留下一些證據(jù)來告訴未來的自己：我們當時是為什么考慮的。
在設計 DSL 時，我往往會創(chuàng)建一個 sample 文件，以記錄過程中，對于不同的要素的思索。如我在設計 Guarding DSL 里，使用了一個 0.0.1.sample 文本文件，來描述早期版本的語法示例：
- # 正則表達式
- package(match("^/app")) endsWith "Connection";
- package("..home..")::name should not contains(matching(""));
- # 簡化的比較
- class::name.len should < 20;
通過一些注釋來讓自己優(yōu)化設計。
實現(xiàn)語法解析
這一部分的過程，和我們學習編譯原理時基本是一致的。不過呢，在編寫領(lǐng)域特定語言的時候，我們一般會使用解析器生成器，而不是手寫解析器。
細節(jié)設計
設計領(lǐng)域特定語言的時候，在設計語法上的拘束不會像通用語言那么多。所以，自由設計的范圍就大一點，有些內(nèi)容也不一定需要像編程語言麻煩。諸如于：
- 分隔符
- 縮進的處理
- 語法塊的開始和結(jié)束
- ……
PS：使用類似于編程語言的寫法，對于寫 DSL 的非編程人士來說可能會變成一種困擾。
解析器生成器
經(jīng)典的 Lex & Yacc 是你可以考慮的范圍，在不同的語言里也有一些相似的實現(xiàn)。
對于我來說，以下是我常用的一些解析器生成器。
- Antlr。支持主流的語言
- Peg.js。JavaScript
- Pest。Rust
- Lalrpop。Rust
我還是比較習慣用 Antlr，支持的語言較多。我與同事以及開源社區(qū)的小伙伴們，在下面的項目中都使用過 Antlr：
- Coca = Golang + Antlr
- Unflow = Rust + Antlr
- Lemonj = JavaScript/TypeScript + Antlr
- Chapi = Java/Kotlin + Antlr
從使用上它們之間的差距并不大，但是都需要學習成本。
演進語言的設計
最后，讓我們來談談一些有意思的東西，雖說是演進吧，但是，和設計暫時沒有太大的關(guān)系。
測試驅(qū)動開發(fā)
經(jīng)我大量發(fā)現(xiàn)，TDD 是非常適合于編程語言的開發(fā)與設計。需求是未知的，易于發(fā)生變化的，還需要覆蓋足夠全的場景。
從實踐的層面上來說，主要是有兩種：
- 面向語法的測試。即，只讓語法編譯能通過，但是不報錯。
- 面向功能的測試。即，驗證某一部分的語法是正確的。
- 面向用例的測試。即，驗證符合使用場景。
自動化語言遷移
原先這部分的標題是，向下兼容。但是，我一直覺得向下兼容不是一個好主意。所以呢，我就想了想把在其它領(lǐng)域的經(jīng)驗搬了過來，于是呢，內(nèi)容就變成了自動化語言遷移。
在關(guān)于版本的遷移上，我覺得 Angular 語言上關(guān)于版本的自動化遷移，是值得我們?nèi)ソ梃b的。當然了，采用這種設計的成本非常高，我們需要有一個專門的團隊，使用工具自動化分析舊的系統(tǒng)，并使用工具來自動修改舊的代碼。
其它
文中相關(guān) DSL 鏈接(歡迎加入 Inherd 一起編寫 DSL)：
Unflow: https://github.com/inherd/unflow
Guarding: https://github.com/inherd/guarding
Forming: https://github.com/inherd/forming
本文轉(zhuǎn)載自微信公眾號「phodal」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系phodal公眾號。
