淺析 DDD 領域驅動設計

一、前言

最近公司一場有關于領域驅動設計的技術分享會，主要講解了服務的劃分，Restful API的設計，如何將抽象具有統一業務的范疇的Model，使其模塊化，同時能夠提煉組合多個模塊，使得業務能夠獨立服務化，在軟體開發中如何降低系統的復雜度是一個永恒的挑戰，在之前都是通過一系列的設計模式或者范例來降低一些比較常見的復雜度，這些都是通過技術手段來解決技術問題，沒有從根本上解決業務上的問題，但是在03年 Eric Evans 的《Domain Driven Design》 中，才是真正的從業務的角度出發，并且提供了一整套的針對純業務開發的架構思路，為了更加深入理解，看了不少資料后，對DDD有了一點小小的個人心得，所以整理了一下，分享出來，希望能夠對大家有幫助，

二、什么是DDD

DDD 是 Eric Evans 在2003年出版的書名，同時也是這個架構設計方法名的起源，Eric Evans “領域驅動設計之父”，世界杰出軟體建模專家，他創建的 “Domain Language” 公司，就是致力幫助公司機構創建與業務緊密相關的軟體，

DDD 不是一套架構，而是一種架構思想，所以導致在代碼層面缺乏了足夠的約束，因此 DDD 在實際應用中上手門檻比較高，而且在絕大部分公司中實際應用中是沒有應用到的，或者說只是應用到了 DDD 部分思想 比如： 建模的思想，對整個架構體系的思想是無法落地的，而且一些依然火熱的ORM工具（Hibernate）助長了貧血模型的擴散，同樣因為傳統的基于資料庫技術以及MVC的四成架構應用（UI、Business、Data Access、Database）依然能夠為我們解決絕大部分的應用開發，

之前的服務架構 局限于單機 +LB 用MVC提供的Rest介面提供外部服務呼叫，或者用WebService 做RPC呼叫，到了2014年，SOA開始火熱起來了，微服務開始如雨后春筍一樣的開始冒頭，怎么把一個應用或者專案合理化的進行拆分多個微服務，成為了各個技術負責人的思考的重點，而在DDD里面的 Bounded Context（限界背景關系）中就為我們提供了一整套合理的架構思想，

但是 DDD 可以讓我們思考 在我們的專案中哪些是可以被服務化拆分，哪些業務邏輯需要被聚合在一起，實作最小的開發和維護成本，

三、領域驅動設計-基本概念

DDD 的全稱為 Domain Driven Design，即領域驅動設計，DDD不是架構，而是一種方法論（Methodology），微服務架構從一出來就沒有很好的理論支撐如何合理的劃分服務邊界，

在我們早期常見的軟體開發就是拿到產品需求后，先考慮資料庫設計，根據資料庫設計，建立對應的物體層、服務層等等，但是這種方式會將 分析、設計和業務需求脫節，而更多的是直接考慮應該如何實作，這就有點本末倒置了，而DDD 是從問題本身出發進行的設計方法，

概念： 系統設計應該是一種以領域為核心的設計和開發，設計應該通過維護一個深度反應領域概念的模型，以及提供可行的經過實踐校驗的大量模式來應對領域的復雜性，

DDD 更像小顆粒的迭代設計，最小單元是 領域模型(Domain Model)

什么是領域（Domain）？

什么是領域？比如我們經常使用的某寶、某東、屬于網上電商領域，那么這些領域就會有對應的商品瀏覽、購物車、下單、扣減庫存、供應商、付款等等核心環境，再比如我們想做一個聊天系統，那這個系統的核心業務就要確定，比如有 聯系人、分組、朋友圈、視頻、聊天記錄等功能，

所以，我們可以得知，一個領域的本質上可以理解為一個問題域，只要是同一個領域的，那么他們 一定會有相同的問題域，因此只要我們確定了系統所屬的領域，那這個系統的核心業務，也就是我們要解決的關鍵問題，問題的范圍邊界也就基本確定了，

什么是設計（Design）？

DDD 中的設計主要是指領域模型的設計，為什么說是領域模型的設計而不是架構設計或者其他的設計？因為DDD是一種基于模型驅動開發的軟體開發思想，強調領域模型是這個系統的核心，領域模型也是整個系統的核心價值所在，每一個領域，都有對應的領域模型，因為領域模型能夠很好的幫助我們解決復雜的業務問題，
領域模型系結了領域和代碼的是吸納，確保了最終的代碼實作就一定是解決了領域中的核心問題，

四、四色原型建模

簡單描述： 某個人（Party）的角色（PartyRole）在某個地點（Place）的角色（PlaceRole）用某個東西（Thing）的角色（ThingRole）做了某件事情（MomentInterval）

PartPlaceThing：簡稱PPT，用淡綠色表示，常見的PPT有：部門、崗位、人員、地點、物品等，

Description：簡稱Des，用淡藍色表示，主要用來對PPT進行描述，常見的Des有：部門型別、崗位層級、人員型別、地點區域、物品分類等，

Role：用淡黃色表示，主要表示PPT在某個場景下扮演的角色，常見的角色有：財務類部門、管理類崗位、請假者、銷售點、產品等，

MomentInterval：簡稱MI，用淡紅色表示，主要表示在一刻或一段時間內發生的一件事情，常見的MI有：部門移動、崗位移動、員工離職、產品銷售等，

MomentInteval：簡稱MIDetail，用淡紅色表示，主要表示MI的明細，

五、分層架構

分層架構是將軟體模塊按照水平切分的方式分成多個層

最基本的是分層架構是三層：即表現層，領域層和資料持久層

DDD中 四層架構：表現層，應用層、領域層和基礎層

四層中的應用層是對三層架構中領域層進行進一步拆分，但是無論怎么分層，業務邏輯永遠在領域層，

三層架構：
- 表現層： 負責向用戶展示資訊和接收用戶的指令，需要負責處理展示邏輯，比如用戶通過我們的系
統進行信用卡還款，系統會回傳三個狀態未申請，處理中，處理完成，表面層需要根據這個狀態給
用戶回傳不同的頁面，根據這三個不同的狀態，向用戶展示不同的中文說明，
- 領域層： 負責表達業務邏輯，是整個系統的核心層，比如信用卡還款服務，
- 持久層： 提供資料查詢和存盤服務，包括按照狀態查詢信用卡，

四層架構：

• 表現層： 同三層架構表現層，
• 應用層： 定義軟體要完成的任務，不包含業務邏輯，而是協調，比如受理用戶請求的任務，負責非
  業務邏輯（批量洗掉、修改等）
• 領域層： 同三層架構領域層，
• 基礎層： 為各層提供通用的技術能力，為領域層提供資料和檔案存盤，

分層架構最重要的是每一層關注自己的職責，持久層只負責提供查詢、更新和存盤資料的服務，和業務邏輯無關的，所以持久層提供按斬訓款狀態查詢信用卡的服務，這樣做的好處增加復用性，后續領域層提供展示已還款的信用卡服務時能復用持久層的查詢服務，

分層架構的好處

分層架構的目的是通過關注點分離來降低系統的復雜度，同時滿足單一職責、高內聚、低耦合、提高可復用性和降低維護成本，
單一職責：每一層只負責一個職責，職責邊界清晰，如持久層只負責資料查詢和存盤，領域層只負
責處理業務邏輯，
高內聚： 分層是把相同的職責放在同一個層中，所有業務邏輯內聚在領域層，這樣做有什么好處呢？試想一下假如業務邏輯分散在每一層，修改功能需要去各層修改，測驗業務邏輯需要測驗所有層的代碼，這樣增加了整個軟體的復雜度和測驗難度，

低耦合： 依賴關系非常簡單，上層只能依賴于下層，沒有回圈依賴，

可復用： 某項能力可以復用給多個業務流程，比如持久層提供按斬訓款狀態查詢信用卡的服務，既可以給申請信用卡做判斷使用，也可以給展示未還款信用卡使用，

易維護： 面對變更容易修改，把所有對外介面都放在對外介面層，一旦外部依賴的介面被修改，只需要改這個層的代碼即可，

以上這些既是分層的好處也是分層的原則，大家在分層時需要遵循以上原則，不恰當的分層會違背了分層架構的初衷，

分層架構的缺點

分層架構也有幾個缺點
開發成本高： 因為多層分別承擔各自的職責，增加功能需要在多個層增加代碼，這樣難免會增加開發成本，但是合理的能力抽象可以提高了復用性，又能降低開發成本，
性能略低： 業務流需要經過多層代碼的處理，性能會有所消耗，
可擴展性低： 因為上下層之間存在耦合度，所有有些功能變化可能涉及到多層的修改，

六、領域模型(domain model)

領域模型是對領域內的概念類或現實世界中物件的可視化表示，又稱概念模型、業務物件模型、領域物件模型、分析物件模型，

它專注于分析問題領域本身，發掘重要的業務領域概念，并建立業務領域概念之間的關系，

優點是系統層次結構清楚，各層之間單向依賴， Client -> (Business Facade) -> Business Logic -> Data Access Object 可見，領域物件幾乎只做傳輸介質的用處，不會影響到層次的劃分，

領域物件只是作為保存狀態或者傳遞狀態使用，它是沒有生命的，只是資料沒有行為的物件不是真正的物件，

七、貧血模型

貧血模型是指領域物件里只有 get 和 set 方法（一般是指POJO）,所有的業務邏輯是不包含在這里面的而是放在 Business Logic層，

在使用Spring的時候，通常就暗示著我們使用的是貧血模型，我們把Domain類用來單純地儲存資料，Spring管不著這些類的注入和管理，Spring關心的邏輯層（比如單例的被池化了的Business Logic層） 可以被設計成Singleton的Bean，

假設我們這里改變一下，就在Domain類中提供業務邏輯方法，那么我們在使用Spring構造這樣的資料Bean的時候會遇到很多麻煩，比如 Bean之間的參考，可能引起大范圍的Bean之間的潛逃構造器的呼叫，

八、充血模型

大多業務邏輯和持久化放在Domain Object 里面，Business Logic只是簡單封裝部分業務邏輯以及控制事務、權限等，這樣層次結構就變成 Client -> (Business Facade) -> Business Logic -> Domain Object -> Data Access Object，

優點：

是面向物件，Business Logic 符合單一職責，不像在貧血模型里面那樣包含所有的業務邏輯太過沉重，

缺點

如何劃分業務邏輯，什么樣的邏輯應該放在 Domain Object中，什么樣的業務邏輯應該放在Business Logic中，其實是比較模糊的，

即使劃分好了業務邏輯，由于分散在Business Logic和Domain Object層中，不能更好的劃分模塊開發，

熟悉業務邏輯的開發人員需要滲透到Domain Logic中去，而在Domain Logic又包含了持久化，對于開發者者這是十分混亂的，

如果Business Logic要控制事務并且為上層提供一個統一的服務呼叫入口點，它就必須把在Domain logic里實作的業務邏輯全部重新包裝一遍，完全屬于重復勞動，

使用RoR開發時，每一個領域模型物件都可以具備自己的基礎業務方法，通常滿足充血模型的開發，充血模型更適合復雜業務邏輯的設計開發，

充血模型的層次和模塊的劃分是一門學問，對開發人員要求也比較高，可以考慮定義這樣的一些規則：
（1） 事務控制不要放在領取模型的物件中實作，可以放在facade中完成，
（2） 領域模型物件中只保留該模型驅動的一般方法，對于業務特征明顯的特異場景方法呼叫放在facade中完成，

九、傳統的資料驅動開發模式

View、Service、Dao 這種三層模式，開發者會很自然的寫出程序式代碼，這種開發方式中的物件只是資料載體，而沒有行為，是一種貧血物件模型，以資料為中心，以資料庫ER圖為設計驅動，分層架構在這種開發模式下可以認為是資料處理和實作的程序，

十、限界背景關系(Bounded Context)

限界背景關系：定義了每個模型的應用范圍

一個業務領域可以劃分成多個BC，它們之間通過Context Map進行集成，BC是一個顯式的邊界，領域模型Bianc便存在于這個邊界之內，領域模型是關于某個特定業務員領域的軟體模型，通常，領域模型通過物件模型來實作，這些物件同時包含了資料和行為，并且表達了準確的業務含義，

關于限界背景關系，有一個很形象的類別，細胞和細胞膜的類比：

細胞之所以能存在，是因為細胞膜定義了什么在細胞內，什么在細胞外，而且確認了什么物質可以通過細胞膜

BC可以類比為細胞膜，大型系統由于其復雜性，對于一個物件如果采取統一建模方式，可能會產生不可預測的效果，例如書中提到的客戶發票中的收費物件故障，其實類似問題也在很多地方可以看到，

十一、什么是 CQRS？

CQRS —— Command Query Responsibility Segreation（命令查詢職責分離），故名思義是將 command 與 query 分離的一種模式，這種命令與查詢的分離方式，可以更好地控制請求者的操作，查詢操作不會造成資料的修改，因而它屬于一種冪等操作，可以反復地發起，而不用擔心會對系統造成影響，基于這種特性，我們還可以為其提供快取，從而改進查詢的性能，

query很好理解，就是我們經常使用到的查詢，

那么 command 又是什么呢，我們可以看 CRUD，其實可以分為讀（R）和寫（CUD），大部分情況就是一個方法要么是執行一個Command完成一個動作，要么就是查詢回傳資料，比如我們回答問題的人不應該去修改問題，

只要充分理解了運用CQRS模式的意圖，理解CQRS模式就變得容易了許多，下圖是CQRS框架AxonFramework官方檔案給出的CQRS架構圖，

十二、統一語言(Ubiquitous Language)

業務人員和我們使用一樣的語言，我們的程式比如讓業務盡量集中在領域里，比如在傳統的資料驅動里，如果說 張三喜歡李四，我們一般會這么寫

UserService.Love(zhangsan, lisi)

但是我們業務人員很奇怪誰Love誰？ 為什么要UserService?, 如果我們寫成下面這樣

zhangsan.Love(lisi)

如果我們用

Company.hire(employee)
來替代
companyservice.hire(company,employee)

這樣我們就更容易讓業務人員參與進來，而且代碼可以更易于表示真實的業務場景，

以上是根據課堂筆記來記錄的，如果有錯誤或者不懂的地方，歡迎大家在下面留言，

我是牧小農，怕什么真理無窮，進一步有進一步的歡喜！