軟體系統是通過軟體開發來解決某一個業務領域或問題單元而産生的一個傳遞物。而通過軟體設計可以幫助我們開發出更加健壯的軟體系統。是以，軟體設計是從業務領域到軟體開發之間的橋梁。而DDD是軟體設計中的其中一種思想，旨在提供一種大型複雜軟體的設計思路和規範。通過DDD思想可以讓我們的業務架構、系統架構、部署架構、資料架構、工程架構等都具備高擴充性、高維護性和高測試性。
但是落地DDD是一件很困難的事情。首先在思想認知層面就比較難以突破。
DDD本身是一種思想，不是某種具體的技術，是以在代碼實作和系統架構層面沒有限制。而由于市面上成熟的ORM架構(比如hibernate、mybatis等)，使得大部分軟體開發都是直接面向資料庫開發。在傳統開發中的應用分層架構又和DDD思想的分層架構很類似。進而導緻很多人在初學DDD時有一定的了解偏差，進而導緻無法落地DDD思想。
這篇文章記錄我對DDD的學習、感悟與項目工程代碼重構實戰心得！
一、Domin Primitive
領域“中繼資料”的意思。主要是講解領域的基本準則。這也是使用DDD思想的基本準則。
1.1 隐性的概念顯性化
exp：電話号碼通常是由區号編碼+号碼組成。在實際的業務中會有很多需要電話号碼的業務。比如登入認證、導購分銷等業務；我們需要對電話号碼進行基礎性校驗；擷取區号編碼等；在正常操作下，會在每一個用到電話号碼的方法入口都會寫大量的這種校驗代碼和判斷代碼，盡管我們可以将它的校驗和擷取區号編碼抽離成util類（實際上大多數工程中都是這麼做的），但這種方式治标不治本。基于DDD思想可以發現這裡有一個隐性概念：區号編碼。
我們可以基于DDD思想，将電話号碼建立為一個擁有獨立概念和行為的值對象：PhoneNumber，将基礎性校驗和擷取編碼等無狀态行為封裝在值對象中。這樣在方法中就不需要再充斥着寫大量的校驗和判斷。
1.2 隐性的上下文顯性化
exp：在銀行轉賬場景中，通常我們會說A賬戶給B賬戶轉1000元。這裡的1000元實際上有兩層含義，數字1000，貨币元。但我們通常會忽略貨币機關元。導緻在實作轉賬功能時，沒有考慮到機關。一旦有國際轉賬時，就又會陷入到大量的if else中。
我們基于DDD思想，将錢建立為一個擁有獨立概念和行為的值對象：Money，這樣我們所說的錢才具備完整的概念。通過這種方式就可以将貨币這個隐性上下文顯性化，進而避免目前未識别到但是未來可能會爆雷的bug。
1.3 封裝多對象行為
exp：在跨境轉賬的場景中，需要轉換匯率，我們可以将轉換匯率封裝成一個值對象。通過封裝金額計算邏輯和各種校驗邏輯，使得整個方法極其簡單。
1.4 DP和值對象的差別
DP是阿裡大神提出來的概念；值對象是DDD思想中的概念。
學習之後，我個人認為DP是對值對象的進一步補充，使其擁有了更加完整的概念。在值對象【不變性】的基礎上補充了【可校驗性】和【獨立行為】。當然也是要求【無副作用】。所謂的無副作用就是【狀态不可變】。
1.5 DP和DTO的差別
| DTO | DP | |
| 功能 | 資料傳輸對象，屬于技術細節 | 屬于領域中的業務概念 |
| 資料關聯性 | 不具備資料關聯性 | 資料之間有強關聯性 |
| 行為 | 無行為 | 擁有十分豐富的行為和業務邏輯 |
1.6 使用DP VS 不使用DP
| 不使用DP | 使用DP | |
| API接口清晰度 | 含混不清 | 方法簽名清晰易懂 |
| 資料校驗、錯誤處理 | 校驗邏輯分布多個地方、大量重複代碼 | 校驗邏輯内聚，在方法邊界外完成 |
| 業務代碼的清晰度 | 充斥大量膠水代碼，淹沒業務核心邏輯 | 代碼簡潔明了，業務邏輯一目了然 |
| 測試複雜度 | TC數量：NMP(N個參數，每個參數M種校驗，有P個方法在調用) | TC數量：N+M+P |
| 其他好處 | 整體安全性大大提升、不可變性、線程安全 |
二、應用架構
2.1 DDD思想下的标準應用架構
傳統的MVC架構分為展現層、業務邏輯層和資料通路層，更加注重從展現層到資料通路層自上而下的互動，編寫出來的代碼像是腳本式代碼。
而基于DDD原則，工程架構被分為應用層、領域層和基礎設施層。将工程中不同的功能和職責劃分到不同的層級中。核心的業務邏輯放在領域層中。
2.1.1 應用層
按照DDD的思想，應用層負責協調使用者界面和領域層之間的互動。可以通俗的認為是對領域服務的編排，其本身不包含任何業務邏輯。
2.1.2 領域層
領域層負責實作核心業務的邏輯和規則。按照DDD的思想，這一層包含實體子產品、值對象子產品、事件、領域服務。
2.1.3 基礎設施層
基礎設施層不處理任何業務邏輯，隻包含基礎設施，通常包含資料庫、定時任務、MQ、南向網關、北向網關等。
2.2 我對演進出六邊形架構的了解
2.2.1 再談應用層
在實際業務邏輯當中，除了使用者界面層之外，還有其他外部系統會調用本服務，比如xxljob、MQ、或者提供給外部系統調用http或者rpc接口等。是以在實際當中，應用層應當是協調外部系統與領域層之間的互動。
按照标準架構層級依賴關系來看，應用層依賴了領域層和基礎設施層。由于依賴了基礎設施層，是以破壞了應用層本身的可維護性和測試性。是以我們需要基于接口進行依賴倒置。
為了防止領域概念外洩，需要對應用層進一步的抽象為外部服務和内部服務，所有外部服務必須通過内部服務調用領域層。這樣就可以防止領域模型的外洩。
2.2.2 再談領域層
同樣的，按照标準架構層級依賴關系，領域層依賴基礎設施層，但這也破壞了領域層本身的可維護性和可測試性。是以我們基于DDD中的資源庫思想，抽象repository層，通過接口實作依賴反轉。讓領域層不再依賴基礎設施層。進而提高領域層本身的可維護性和可測試性。
2.2.3 再談基礎設施層
對于基礎設施層而言，它主要作用是提供基礎設施的能力，比如資料庫、MQ、遠端服務調用等。進一步抽象可以發現它們就是端口和擴充卡。通過端口實作與外部系統的互動，通過擴充卡完成資料和概念的轉換。
2.2.4 演進出六邊形架構
通過依賴反轉，神奇的事情發生了。基礎設施層變成了最外層。
我們結合對應用層、領域層和基礎設施層進一步的了解再加上反轉後的應用架構，便可以得到六邊形架構：
2.3 工具類、配置類的代碼應該放在哪裡？
在一個實際的工程當中，除了上面所說的三層之外，通常會使用到一些工具類（JSON解析工具類、字元串工具類等）。各層可能都會使用到工具類。
從工具類的定位來看，它應當屬于基礎設施層，但是基礎設施層屬于最上層，如果放在基礎設施層，那麼就會破壞依賴順序。是以我們在邏輯劃分上可以把工具類歸類為基礎設施或者通用域，在具體的工程結構中，可以單獨一個子產品放工具類。
在實際工程中還有一種類型的代碼是配置相關的。從業務次元劃分的話可以分為業務類配置和基礎設施類配置。是以我們需要根據配置的類型将其放在對應的位置。比如為了靈活應對業務，我們通常會配置一個動态開關，來動态調整業務的邏輯，這種業務開關類的配置就應該放在領域層；再比如資料庫的配置屬于基礎設施配置，這類配置就應當放在基礎設施層。
2.4 我對于項目的六邊形架構的實踐
我們團隊做的的職責是業務底座，包含一系列的基礎能力建設。其中對于IDaaS系統而言，基于六邊形架構實作出以下工程結構：
三、repository模式
3.1 什麼是repository模式？
在DDD思想中，repository表示資源庫的概念，用于區分資料模型和領域模型。它操作的對象是聚合根，是以它屬于領域層。
3.2 為什麼要使用repository模式？
repository模式有兩個非常重要的作用：1、與底層存儲進行解偶；2、為解決貧血模型提供了一種規範。
3.3 什麼是貧血模型？
由于過去ER模型以及主流ORM架構的發展，讓很多開發者對實體的概念還停留在與關系形資料庫映射這個層面。進而導緻實體隻有空洞的屬性，而實體的業務邏輯散落各個service、util、helper、handler等各種角落中。這種現象就被稱為貧血模型現象。
如何判斷自己的工程是否有貧血模型現象？
1、大量的XxxDO或者Xxx：實體對象隻包含與資料庫表映射的屬性，沒有行為或者及其少量的行為；
2、業務邏輯在各種service、controller、util、helper、handler中：實體的業務邏輯散落在不同層級、不同類、不同方法中，相似場景有大量的重複代碼。
3.4 為什麼貧血模型不好？
無法保證明體對象的完整性和一緻性：貧血模型下，實體屬性的狀态和值隻能由調用方保證，但是屬性的get和set是公開的，是以所有調用方都可以調用。是以無法保證對象的完整性和一緻性。
操作實體對象的邊界很難發現：由于對象隻有屬性，屬性的邊界值、調用範圍不受實體自身控制，各個地方都可以調用，邊界值和範圍也隻能由調用方自行保障。如果實體的邊界值有所變化，那麼所有調用方都需要調整，這種情況下很容易導緻bug的産生。
強依賴底層：貧血模型下的實體和資料庫模型映射、協定等。是以如果底層改變，那麼上層邏輯需要全部跟着改變。“軟體”變成了“固件”。
總結一句話：貧血模型下，軟體的可維護性、可擴充性、可測試性極差！
擴充：
軟體的可維護性=底層基礎設施變化時，需要新增/修改的代碼量是多少（越少可維護性越好）
軟體的可擴充性=新增或變更業務邏輯時，需要新增/修改的代碼量是多少（越少可擴充性越好）
軟體的可測試性=每條TC執行的時長 * 新增或變更業務邏輯時産生的TC（時長越低/TC越少，測試性好）
3.5 實際情況中，為什麼貧血模型難以消滅？
1、資料庫思維
随着ER和ORM架構的發展，讓多數開發者在剛入門的時候（自學、教育訓練等方式），就認為實體就是資料庫表映射；進而簡單的将面向業務領域開發轉變成了面向資料庫開發，漸漸地就認為軟體開發就是CRUD。
2、簡單
盡管有些架構師或者開發人員知道貧血模型不好，但是企業為了占領市場，需要快速推出産品。是以工期被壓縮的很厲害。而貧血模型恰好簡單，在軟體初期階段，可以快速實作業務邏輯。進而迫使開發人員不得不“先實作了再說”。這種現象也是行業的普遍現象。
3、腳本思維
有些開發人員具備一定的抽象思維，将一些共性的代碼寫成util、helper、handler等類。但寫代碼依然是腳本思維。比如一個方法中，先來個字段校驗代碼，再來個對象轉換代碼，然後調用遠端服務，對遠端服務傳回的結果再來個對象轉換，……最後調用Dao類的方法儲存對象。這種代碼在很多工程中太常見了。
基于這些因素，導緻貧血模型難以消滅。
這些因素的根本原因是什麼？
根本原因就是，大部分的開發人員混淆了資料模型和領域模型這兩個概念。
資料模型（Data Model）：資料模型解決的是資料如何持久化、如何傳輸的問題；
領域模型（Domin Model）：領域指的是某一個獨立的業務領域或者問題空間，領域模型就是解決這個業務領域或者問題空間而設計的模型；解決的是業務領域的問題。
在DDD中，repository就是用于區分資料模型和領域模型提出來的概念。
3.6 使用repository之後，資料模型和領域模型如何轉換？
使用repository之後，資料模型和領域模型都各司其職。通過Assembler和Converter進行模型之間的轉換。
在代碼中，動态轉換映射 VS 靜态轉換映射
雖然Assembler/Converter是非常好用的對象，但是當業務複雜時，手寫Assembler/Converter是一件耗時且容易出bug的事情，是以業界會有多種Bean Mapping的解決方案，從本質上分為動态和靜态映射。
動态映射方案包括比較原始的 BeanUtils.copyProperties、能通過xml配置的Dozer等，其核心是在運作時根據反射動态指派。動态方案的缺陷在于大量的反射調用，性能比較差，記憶體占用多，不适合特别高并發的應用場景。而BeanUtils等copy類工具隐藏了内部copy的過程，很容易引發bug且不易排查。
MapStruct通過注解，在編譯時靜态生成映射代碼，其最終編譯出來的代碼和手寫的代碼在性能上完全一緻，且有強大的注解等能力。會節省大量的成本。
3.7 代碼層面模型規範和比較
| DO | Entity | DTO | |
| 命名規範 | XxxDO | Xxx | XxxDTO/XxxRequest/XxxVO/XxxCommand等 |
| 代碼層級 | 基礎設施層 | 領域層 | 應用層 |
| 字段名稱标準 | 于資料庫字段保持一緻 | 業務語言 | 和調用方商定 |
| 字段類型标準 | 和資料庫字段保持一緻 | 根據業務特征确定事基礎類型還是值對象 | 和調用方商定 |
| 是否需要序列化 | 不需要 | 不需要 | 需要 |
| 轉換器 | Assembler | Assembler/Converter | Converter |
3.8 代碼層面repository規範
1、接口名命名規範
repository中的接口名不要使用底層存儲的名稱（insert、update、add、delete、query等），而是盡量使用具有業務含義的命名。比如save、remove、find等。
2、接口的參數規範
repository操作的對象是聚合根。是以隻能操作聚合根或者實體。這樣才能屏蔽底層的資料模型，避免資料模型滲透到領域層。
四、領域層設計規範
4.1 實體類
大多數DDD架構的核心都是實體類，實體類包含了一個領域裡的狀态、以及對狀态的直接操作。Entity最重要的設計原則是保證明體的不變性（Invariants），也就是說要確定無論外部怎麼操作，一個實體内部的屬性都不能出現互相沖突，狀态不一緻的情況。
4.1.1 建立即一緻
constructor參數要包含所有必要屬性，或者在constructor裡有合理的預設值。
4.1.2 使用Factory模式來降低調用方複雜度
由于建立即一緻的原則，導緻實體的構造方法可能會很複雜，是以可以使用Factory模式來快速的構造出一個新的實體。降低調用方的複雜度。
4.1.3 盡量避免public setter
一個最容易導緻不一緻性的原因是實體暴露了public的setter方法，特别是set單一參數會導緻狀态不一緻的情況。如果需要改變狀态，盡量語義化方法名稱。
4.1.4 通過聚合根保證主子實體的一緻性
通常主實體會包含子實體，這時候主實體就需要起到聚合根的作用，即：
- 子實體不能單獨存在，隻能通過聚合根的方法擷取到。任何外部的對象都不能直接保留子實體的引用
- 子實體沒有獨立的Repository，不可以單獨儲存和取出，必須要通過聚合根的Repository執行個體化
- 子實體可以單獨修改自身狀态，但是多個子實體之間的狀态一緻性需要聚合根來保障
exp：常見的電商域中聚合的案例如主子訂單模型、商品/SKU模型、跨子訂單優惠、跨店優惠模型等。
4.1.5 不可以強依賴其他聚合根實體或領域服務
一個實體的原則是高内聚、低耦合，即一個實體類不能直接在内部直接依賴一個外部的實體或服務。
對外部對象的依賴性會直接導緻實體無法被單測；
以及一個實體無法保證外部實體變更後不會影響本實體的一緻性和正确性。
正确依賴外部的方式
隻儲存外部實體的ID：這裡我再次強烈建議使用強類型的ID對象，而不是Long型ID。強類型的ID對象不單單能自我包含驗證代碼，保證ID值的正确性，同時還能確定各種入參不會因為參數順序變化而出bug。
針對于“無副作用”的外部依賴，通過方法入參的方式傳入。比如上文中的equip(Weapon，EquipmentService）方法。
4.1.6 任何實體的行為隻能直接影響到本實體（和其子實體）
這個原則更多是一個確定代碼可讀性、可了解的原則，即任何實體的行為不能有“直接”的”副作用“，即直接修改其他的實體類。這麼做的好處是代碼讀下來不會産生意外。
另一個遵守的原因是可以降低未知的變更的風險。在一個系統裡一個實體對象的所有變更操作應該都是預期内的，如果一個實體能随意被外部直接修改的話，會增加代碼bug的風險。
4.1.7 可以利用enum來代替繼承關系，後續也可以利用Type Object設計模式來做到資料驅動
4.2 領域服務
當一個業務邏輯需要用到多個領域對象作為輸入，輸出結果是一個值對象時，就說明需要使用到領域服務。
4.2.1 單對象政策型
這種領域對象主要面向的是單個實體對象的變更，但涉及到多個領域對象或外部依賴的一些規則。
在這種類型下，實體應該通過方法入參的方式傳入這種領域服務，然後通過Double Dispatch來反轉調用領域服務的方法。
什麼是Double Dispatch
exp：對于“玩家”實體而言，有一個“equip()”裝備武器的方法。
按照正常思路，“玩家”實體需要注入一個EquipmentService，然而實體隻能保留自己的狀态，
除此之外的其他對象實體無法保證其完整性，是以我們不通過注入的方式使用EquipmentService；
而是通過方法參數引入的方式來使用。即“玩家”實體的"equip()"方法定義為：
public void equip(Weapon weapon, EquipmentService equipmentService) {
if(equipmentService.canEquip(this, weapon)) {
this.weaponId = weapon.getId();
}
}
這種方式就稱為Double Dispatch方式。
Double Dispatch是一個使用Domain Service經常會用到的方法，類似于調用反轉。
4.2.2 跨對象事務型
當一個行為會直接修改多個實體時，不能再通過單一實體的方法作處理，而必須直接使用領域服務的方法來做操作。在這裡，領域服務更多的起到了跨對象事務的作用，確定多個實體的變更之間是有一緻性的。
4.2.3 通用元件型
這種類型的領域服務提供了元件化的行為，但本身又不直接綁死在一種實體類上。他的好處是可以通過元件化服務降低代碼的重複性。
接口元件化來實作通用領域服務
exp：在遊戲系統中，原價、NPC、怪物都是可移動的。是以可以設計一個Movable接口，
讓玩家、NPC、怪物實體實作Movable接口。然後再實作一個MoveService，進而實作一個移動通用服務。
4.3 政策對象（Domain Policy）
Policy或者Strategy設計模式是一個通用的設計模式，但是在DDD架構中會經常出現，其核心就是封裝領域規則。
一個Policy是一個無狀态的單例對象，通常需要至少2個方法：canApply 和 一個業務方法。
canApply方法用來判斷一個Policy是否适用于目前的上下文，如果适用則調用方會去觸發業務方法。
通常，為了降低一個Policy的可測試性和複雜度，Policy不應該直接操作對象，而是通過傳回計算後的值，
在Domain Service裡對對象進行操作。
4.4 副作用的處理方法 - 領域事件
什麼是副作用？
“副作用”也是一種領域規則。一般的副作用發生在核心領域模型狀态變更後，同步或者異步對另一個對象的影響或行為。比如：當用于積分達到100時，會員等級升1級。
在DDD中，解決“副作用”的手段是領域事件。通過EventBus事件總線可以實作領域事件的傳播。
目前領域事件的缺陷和展望
由于實體需要保證完整性，是以不能夠直接依賴EventBus，是以EventBus隻能保持全局singleton。但是全局singleton對象很難被單測，這就容易導緻Entity對象很難被完整單測覆寫全。
五、寫在最後
通過對于DDD的學習與實踐，越來越能夠體會到它作為一種軟體設計思想和指導，對于大型複雜軟體的建設十分有幫助。對于曆史遺留屎山工程的重構也提供了一個很好的指導方向。