小團隊也能做DDD-上篇

作者簡介:胡正軍，御家匯架構團隊負責人，坐標湖南長沙，開發，運維，測驗，大資料均有負責，雜而不精，樂于復雜系統重構，擁抱DDD

上一篇文章說了小團隊也能做中臺，里面提到我們用了領域驅動設計（DDD）這個方法論來開發中臺，本文對我們為什么使用DDD做一個分享，下一篇再講我們怎么實踐的DDD，

DDD出現得很早，2004年Eric Evans就寫了《領域驅動設計：軟體核心復雜性應對之道》，但使用并不廣泛，拿長沙這邊來說，使用的企業可以說是寥寥無幾，

最近幾年DDD隨著微服務反而火了一把，各種技術群里一言不合就DDD，也有一些在線培訓和書籍出版，比如人保的架構師歐創新就在極客時間開了專欄，預計本月還會出版一本書籍，然而大家雖然談論得多，真正落地的少，

我認為原因有:

< 1 >系統不復雜，沒必要用DDD;

< 2 > DDD概念多，理解難，懶得去學;

< 3 > 就算一個人學了也沒用，需要團隊都用起來，由于人性本懶惰，DDD對業務和開發都要求有點高，所以不想做，還是CRUD爽點，

DDD是為了解決復雜業務系統構建的一套方法論，有戰略設計和戰術設計兩大塊，

戰略設計的核心是統一語言和限界背景關系，戰術設計的核心是獨立領域邏輯層，

復雜業務系統為什么要用DDD，可以從3個維度來說明，

這3個維度分別是軟體開發程序，復雜系統設計，模塊編碼，

可以看到這3個維度是一級一級降低維度的，軟體開發程序涉及多個崗位（產品經理，開發，測驗，業務運維），屬于開發流程這個維度，復雜系統設計涉及的崗位是架構師或者高級開發，屬于架構設計這個維度，模塊編碼涉及的崗位主要是開發了，屬于代碼撰寫這個維度，我們先分析這3個維度上有什么問題，再看DDD都能提供什么指導，

一、軟體開發程序

一個簡單系統的開發是不需要分這么多崗位的，大學期間做的一些兼職小專案就是一個人把需求，開發，測驗，運維全做了，效率很高，如果說搞多個崗位多個人來做，反而效率很低，

不過這種情況隨著專案復雜度上升就不一樣了，一個人是沒法搞定所有事情的，于是我們設立了各種崗位，通過團隊分工讓專業的人做專業的事情，

拿開發這個崗位來說還分了前端和后臺開發，也是因為技術復雜性的要求，必須分工，一個理論是建立知識壁壘并能有效交換能提高效率，這個方面詳細的論述可以看下八叉說的視頻，通過專業分工來提升效率在生活中有很多地方都有體現，比如流水線作業什么的，這在國富論和科學管理中也有提到，這個方面詳細的論述可以看下八叉說的視頻，

這里得到第一個結論：

軟體開發程序中的技術知識通過分工建立知識壁壘來提升效率

但是軟體開發還有一類知識是沒法通過分工解決了，上圖箭頭表示的就是領域知識必須隨崗位傳遞，需求分析師把業務轉換成需求檔案，然后這個需求檔案里面的業務知識必須傳遞給開發，開發必須理解清楚了才能干活，現實中確實出現了很多這樣的情況，開發需求都沒理解透，就開始設計編碼，最后做出的東西跟實際業務需求不一樣，返工，開發和產品經理矛盾重重，如何讓業務知識快速傳遞，是迫切需要解決的問題，

這里得到第二個結論：

軟體開發程序中的業務知識需要消除知識壁壘才能提升效率

從兩個結論看好像有沖突，從第一個結論看，分工是有意義的，從第二結論看，不分工反而是好的，隨著各個崗位專業度的提高，分工是必然的，那么怎么解決業務知識傳遞問題， DDD的一個核心模式是統一語言，用于解決解決業務知識傳遞的問題，

統一語言有兩個含義，

1、統一交流語言，我們把業務名詞的含義事先確定好，在業務和技術的各個崗位都統一認知，這樣在交流時，由于對業務名詞的理解已經同頻了，會節省很多溝通成本，

這里舉個沒統一語言的例子，我們公司有個有個渠道的概念，每次討論這個渠道就容易出現每個人理解不一樣，有的把電商平臺一個店鋪當渠道，有的把電商平臺當渠道，還有人理解成其他含義，這是因為每個公司都有些歷史遺留原因對名詞的定義變味道了，

2、統一領域模型和代碼模型，我們知道一個系統最重要的知識沉淀就是代碼和檔案了，當然很多公司都沒檔案，程式員嘛，都一個尿性，恨別人不寫檔案，恨自己寫檔案，想一想當一個新人來接手一個專案，這個專案有一份設計檔案和代碼，設計檔案里面描述的業務模型跟代碼模型不一樣時，我想這個新人是蒙圈的，到底哪個是對的，心里絕對會罵娘，當業務模型和代碼模型一樣，會大大降低我們系統的認知復雜度，

二、 復雜系統設計

為了降低業務系統復雜性，一般是通過分而治之的方式，現在流行的微服務就是基于業務維度進行拆分，那么到底怎么拆分，

如下圖，每個點代表一個領域物件，當很多個物件混合在一起時，設計者或者開發者需要了解所有領域物件，無疑增加了復雜度，如果能找到一種方式合理劃分邊界，讓聯系緊密的物件聚合在一起(比如下圖中形成ABC三個聚合)，聚合之間通過介面互動，那么介面數量會是最少的，有點類似K聚類演算法，總能找到一種最優的劃分方法，當然很多情況下依賴架構設計者的經驗，DDD的限界背景關系提供了一種指導思路，限界背景關系劃分好后，一個限界背景關系可以對應一個微服務，

這里同樣運用了建立知識壁壘可以提升效率這個理論，開發A服務的人實際上不需要了解B服務的內部實行，只需要了解B提供的介面即可，A服務的領域物件數量已經大大下降了，無疑降低了復雜度，

拿一個大學里面的一個學生管理系統來說，涉及到如下領域物件：學生，教師，角色，權限，選單，課程，課程排班，簽到等，

現在來劃分限界背景關系，因為學生和教師都需要登錄和權限，我們一種背景關系分解的方法是鑒權背景關系<角色，權限，選單，學生，教師>， 授課背景關系<課程，課程排班，簽到>，

從關聯度來看，這兩個背景關系需要4個介面來做互動，

由于DDD里面規定限界背景關系一個領域物件有確定的含義，學生和教師這個兩個在鑒權背景關系里面是系統的一個用戶，放到授課背景關系里面代表了兩種不同的身份，也就是當我們說到學生時，到底是需要登錄的一個用戶還是授課里面的學生，含義是不確定的，所以這里缺了一個領域物件用戶，

增加用戶這個領域物件后，限界背景關系重新劃分，只需要2個介面做互動，

三、模塊編碼

傳統的三層結構是web,service,dao，這個大伙都很熟悉，一個業務流程稍微復雜點會導致service里面的代碼變成大泥球，我在上一份作業中，見過一個service類達到上萬行，維護及其痛苦，怎么痛苦法呢，就是每次轉測驗，都會產生20多個bug，改完又會出現新的，一輪一輪無法收斂，我實在受不了，就跟專案經理申請重構，專案經理是不同意的，沒辦法只能立軍令狀，就開干了，最終一萬多行代碼變成4000行左右，bug終于收斂，

解決service層大泥球的一個方法是分離復雜性，把service分為應用層和領域層，這塊內容可以參考王林在infoq的文章

（https://www.infoq.cn/article/A3cgSUWuRulXHl2c_dUr），文章中提到了一個架構原則是業務和技術分離，領域層放業務邏輯，應用層放技術邏輯，復雜性降低，并且領域層更便于測驗，

DDD戰術設計就是把業務邏輯放到最核心位置，整潔架構和六邊形架構也是如此，跟業務相關的代碼寫到物體，值物件和領域服務里面，一些事務，快取等技術相關代碼寫到應用服務里面，

舉例說明：購物車有個操作是添加商品到購物車，應用層ShoppingCartApplicationService把事務，快取處理掉，核心業務邏輯在ShoppingCart這個領域物件里面，

領域層代碼如下：

應用層代碼如下：

四、總結

DDD的統一語言在軟體開發程序中能幫助業務知識更好的傳遞，限界背景關系能指導復雜系統的拆分，戰術設計能幫助代碼更好的分層，

有的公司雖然沒有用DDD這么一套組合拳，可能已經在利用這些好的方法來開發軟體，其實DDD提供一套方法論，也不是必須全部用上，完全可以只借鑒其中一部分，比如DDD的統一語言是通過降低業務知識的傳遞提升效率，可以應用到實際開發中，

舉一個實際的例子，很多企業內部系統也采用了前后端分離，然后用前端開發和后臺開發兩撥人分別開發，再介面聯調，聯調成本很大，完全可以換一種方式，讓后臺開發來做前端，節省聯調成本，

那這里可能有人有疑問，后臺開發做前端會不會效率很低？其實只要讓前端提供了架子和前端組件，再輔助一些組件使用檔案和代碼示例，后臺開發完全可以很快上手，而節省的聯調成本會很可觀，

最后想說一句，方法論能提供指導，但也不要生搬硬套，需要根據自身情況進行裁剪，靈活運用，

—————————— END ——————————

往期推薦

• 2.5 億！華為突然成立新公司
  

• 小團隊也能做中臺（作者原創）
  

• 認知升級：從首席架構師到CTO
  

• 應該這么設計億級用戶秒殺系統！
  

• CTO喬新亮：從死戰沖鋒陷陣的猛將，到掌兵多多益善的元帥
  

技術瑣話

以分布式設計、架構、體系思想為基礎，兼論研發相關的點點滴滴，不限于代碼、質量體系和研發管理，本號由坐館老司機技術團隊維護，

長按掃碼關注

【您的在看，我的莫大鼓勵】