相信很多朋友對領(lǐng)域驅(qū)動設計會有這樣或那樣的困惑，比如領(lǐng)域驅(qū)動設計是什么？它在工作中有什么作用？為什么國內(nèi)關(guān)于這方面的書籍少之又少？…… 為了解決這些疑惑，有幸邀請到專家張逸老師來聊聊領(lǐng)域驅(qū)動設計，下面是 GitChat 獨家采訪記錄。
GitChat：在探討領(lǐng)域驅(qū)動設計問題時，每個人都有每個人的認識，有的時候可能誰也無法說服對方，這時候該怎么辦呢？
張逸：簡單說，就是 show me your code。不管領(lǐng)域設計做得怎么樣，最終都是要落地的，看實現(xiàn)的效果最有說服力。當然，為了保證交流的順暢與效率，代碼這種形式可能容易讓人迷失到紛繁復雜的細節(jié)中去，因此還有一種方式就是 show me your model。
這里說的 model 就是領(lǐng)域模型。注意，團隊在交流領(lǐng)域驅(qū)動設計問題時，不應該只是對建模活動的產(chǎn)出物進行討論，建模的過程同樣非常重要?，F(xiàn)在諸如 Event Storming 等活動都非常強調(diào)利用可視化手段把業(yè)務專家與開發(fā)團隊都包含進來，大家一塊協(xié)作一塊交流，并利用便利貼等工具直觀地展現(xiàn)建?；顒又械拿恳粋€步驟，可以更容易消除誤會與分歧。
GitChat：可以談談領(lǐng)域驅(qū)動設計的流程嗎？比如是先建模？還是做設計？以及應用的場景是什么？
張逸：領(lǐng)域驅(qū)動設計強調(diào)的是將分析、設計與實現(xiàn)統(tǒng)一到一個領(lǐng)域模型中來，同時又相對清晰地劃分為戰(zhàn)略設計和戰(zhàn)術(shù)設計兩個階段。當然，這兩個階段并非瀑布式的，而是迭代和演進的過程。
我認同領(lǐng)域模型對分析、設計與實現(xiàn)的統(tǒng)一，這個思想沒有問題。但在我親身經(jīng)歷的項目中，我還是發(fā)現(xiàn)由于溝通角色與建模目標的不同，分析、設計與實現(xiàn)在三個不同的活動是無法完全統(tǒng)一的，就好像在重構(gòu)時不能實現(xiàn)新功能，這三頂帽子自然也不能同時戴起來。因此，我在《領(lǐng)域驅(qū)動戰(zhàn)術(shù)設計實踐》課程中，清晰地將這三個活動稱之為領(lǐng)域分析建模、領(lǐng)域設計建模與領(lǐng)域?qū)崿F(xiàn)建模，它們各自的產(chǎn)出是領(lǐng)域分析模型、領(lǐng)域設計模型與領(lǐng)域?qū)崿F(xiàn)模型，這三者合起來就是領(lǐng)域模型，而這個過程就是領(lǐng)域模型驅(qū)動設計。
之所以在模型驅(qū)動設計前面加上“領(lǐng)域”作為定語，是因為我認為二者不能劃等號，例如采用數(shù)據(jù)模型的，同樣是模型驅(qū)動設計。在《領(lǐng)域驅(qū)動戰(zhàn)術(shù)設計實踐》GitChat 課程中，我根據(jù)建模視角的不同，將其分別定義為數(shù)據(jù)模型驅(qū)動設計、服務模型驅(qū)動設計、領(lǐng)域模型驅(qū)動設計，并用了相當篇幅的內(nèi)容分別介紹了這三種不同的模型驅(qū)動設計過程。
GitChat：針對一些設計能力不足的開發(fā)團隊，可以采用領(lǐng)域驅(qū)動設計來改進設計和編碼質(zhì)量嗎？
張逸：我個人的觀點，這二者之間有關(guān)系，但并非必要關(guān)系。領(lǐng)域驅(qū)動設計的關(guān)鍵不是設計能力，而是要抓住設計的驅(qū)動力，必須是領(lǐng)域，且必須要求領(lǐng)域?qū)＜覅⑴c到分析建?；顒又衼怼?/p>
要說明的是，這個所謂“領(lǐng)域?qū)＜摇辈皇且粋€頭銜，也不是對技能級別的要求，它其實就是一個指代，代表“懂業(yè)務”的人：可以是客戶，可以是 Product Owner，可以是業(yè)務分析師，可以是產(chǎn)品經(jīng)理，也可以是懂業(yè)務的開發(fā)人員，甚至可以是一個負責業(yè)務分析的團隊。
領(lǐng)域驅(qū)動設計能否成功，還是要看建模尤其是分析建模做得是否足夠好，這其實是整個設計過程的上游。至于設計能力，則要看領(lǐng)域驅(qū)動設計與什么樣的編程范式結(jié)合？常見的編程范式包括結(jié)構(gòu)范式、對象范式和函數(shù)范式。因此這里的“設計能力不足”，究竟指的是哪方面的設計能力不足呢？
當然，從主流的領(lǐng)域驅(qū)動設計來看，主要采用的還是對象范式的設計思想與領(lǐng)域驅(qū)動設計結(jié)合，這就要求團隊掌握基本的面向?qū)ο笤O計能力。這方面能力不足的團隊，確實會影響到最終的設計和編碼質(zhì)量。這是必須要正視的問題，因此我建議那些希望實踐領(lǐng)域驅(qū)動設計的團隊，不要忘了去提高團隊的面向?qū)ο笤O計能力。
提升設計能力并非一朝一夕就可以做到。正是考慮到面向?qū)ο笤O計能力不足對領(lǐng)域驅(qū)動設計的影響，我在《領(lǐng)域驅(qū)動戰(zhàn)術(shù)設計實踐》GitChat 課程中嘗試總結(jié)了一個相對固化的設計過程。這個過程結(jié)合了 DCI、職責驅(qū)動設計等設計方法，它不要求團隊掌握太多面向?qū)ο笤O計思想、原則與模式，只要懂業(yè)務，完全可以以“知其然而不知其所以然”的方式去實踐領(lǐng)域驅(qū)動設計。
這種方法不能讓你的設計變得非常優(yōu)秀，卻可以保證你的設計不至于太糟糕，甚至可以說是不錯的設計。
GitChat：應用服務與領(lǐng)域服務的區(qū)別是什么呢？
張逸：這個是老生常談的問題了。從分層架構(gòu)的角度看，應用服務屬于應用層，領(lǐng)域服務屬于領(lǐng)域?qū)印脤邮且粋€包裝的外觀，按照該層的職責來說，應用服務根本就不該干業(yè)務的活兒，它只是一個對外公開的接口而已。
從業(yè)務粒度看，應用服務的每個公開方法會對應一個具有業(yè)務價值的業(yè)務場景或者說用例。領(lǐng)域服務則不然，它實現(xiàn)了業(yè)務功能，這個業(yè)務功能或者是無狀態(tài)的，又或者是因為需要協(xié)調(diào)多個聚合，又或者需要和外部資源協(xié)作。
在針對業(yè)務場景驅(qū)動設計時，應用服務的一個方法往往會暴露給調(diào)用者，然后它再將該請求委派給領(lǐng)域?qū)拥膶ο?。一般要求領(lǐng)域服務的粒度要小，這樣可以避免設計為事務腳本的過程方式，也可以在一定程度上避免貧血模型。
總結(jié)：
- 應用服務：一組面向業(yè)務場景的業(yè)務外觀方法，只是一個對外提供接口、對內(nèi)分配職責的協(xié)作對象，屬于應用層。
- 領(lǐng)域服務：一個領(lǐng)域服務對應最多一個業(yè)務場景，往往需要和聚合、Repository、甚至領(lǐng)域服務一起協(xié)作。
GitChat：已經(jīng)上線的《領(lǐng)域驅(qū)動戰(zhàn)略設計實踐》與剛上線的《領(lǐng)域驅(qū)動戰(zhàn)術(shù)設計實踐》之間的區(qū)別是？有學習的先后順序嗎？
張逸：這兩個課程剛好對應領(lǐng)域驅(qū)動設計的戰(zhàn)略設計與戰(zhàn)術(shù)設計。
前者強調(diào)系統(tǒng)層面的架構(gòu)模式，包括限界上下文、上下文映射、分層架構(gòu)等，可以運用這些模式對整個系統(tǒng)的領(lǐng)域進行“分而治之”，從而降低業(yè)務復雜度，同時圍繞“領(lǐng)域”為核心，建立業(yè)務復雜度與技術(shù)復雜度的邊界。
后者強調(diào)領(lǐng)域?qū)用娴脑O計模式，以“模型驅(qū)動設計”為主線，貫穿分析、設計與編碼實現(xiàn)這三個不同的建?；顒樱⒁腩I(lǐng)域驅(qū)動設計的戰(zhàn)術(shù)設計要素，如實體、值對象、領(lǐng)域服務、領(lǐng)域事件、聚合、資源庫、工廠等。
當然在我的《領(lǐng)域驅(qū)動戰(zhàn)術(shù)設計實踐》課程中，我擴大了領(lǐng)域驅(qū)動戰(zhàn)術(shù)設計的范疇，講解了數(shù)據(jù)模型驅(qū)動與服務模型驅(qū)動，探討了建模范式與編程范式之間的關(guān)系。同時，在設計過程中，我引入了職責驅(qū)動設計和 DCI 模式來闡釋實體、值對象、領(lǐng)域服務與應用服務之間的協(xié)作關(guān)系。在編碼實現(xiàn)過程中，我又引入了測試驅(qū)動開發(fā)來推進從設計模型到實現(xiàn)模型。
戰(zhàn)略設計和戰(zhàn)術(shù)設計并非單向的過程，而是一個迭代演進與不斷融合的過程。整體來講，前者更偏向于架構(gòu)設計，后者更偏向于詳細設計與編碼。主要還是看讀者的關(guān)注點與側(cè)重點，并沒有一個絕對的學習先后順序。我個人還是建議先學習《領(lǐng)域驅(qū)動戰(zhàn)略設計實踐》，雖然它更偏向于理論，難度更高一些，但是它畢竟概括了領(lǐng)域驅(qū)動設計的全貌。
GitChat：「戰(zhàn)略」這個課程分析了“EAS 系統(tǒng)”，在「戰(zhàn)術(shù)」課程也介紹了“EAS 系統(tǒng)”，兩者的側(cè)重點有什么不同嗎？
張逸：與戰(zhàn)略設計和戰(zhàn)術(shù)設計的側(cè)重點一樣，在「戰(zhàn)術(shù)」課程中，會針對 EAS 系統(tǒng)進行領(lǐng)域建模，并最終對其進行編碼實現(xiàn)。從內(nèi)容來看，后者會更接地氣一些，畢竟講的是落地的實現(xiàn)。
將戰(zhàn)略和戰(zhàn)術(shù)的 EAS 系統(tǒng)案例結(jié)合起來，就是一個系統(tǒng)的完整設計案例了。
到這里，訪談錄的內(nèi)容就結(jié)束了，大家若對 DDD 的內(nèi)容比較感興趣的話，歡迎訂閱本課程，有任何關(guān)于本課程內(nèi)容的疑惑可在讀者圈留言或加群交流~
