一、前言
DDD（領域驅動設計）的一些介紹網上資料很多，這里就不繼續描述了，
自己使用領域驅動設計摸滾打爬也有2年多的時間，出于對知識的總結和分享，也是對自我理解的一個公開檢驗，介于博客園這個平臺也算是對DDD的推廣盡了一份綿薄之力，
一開始接觸這個東西是在2014年，真的覺得像是發現了一片新大陸一般，對我整個程式開發視野有了新的理解，但是像[Vaughn Vernon]《實作領域驅動設計》里寫的那樣，景色雖好，可是自己很長一段時間內很混亂，理不清眼前的陌生世界，因為它與傳統的觀念完全不同，
我相信大部分同學剛接觸DDD的時候也會有一樣的感覺，
這次開始寫這系列，也希望有越來越多的人能夠加入到DDD的佇列中，在我之前，園子里的netfocus、dax.net、田園里的蟋蟀等園友都已經對推廣DDD做了很多事情，再此感謝下各位，這些分享在我學習DDD的道路上給予了很多幫助，
本次系列中多處參考[Vaughn Vernon]《實作領域驅動設計》一書里的陳述句，我認為此書可以作為各位進入DDD的敲門磚，希望大家能夠去拜讀一下此書，
二、名詞解釋
首先我覺得有必要先把DDD中的常用名詞做一個解釋，
界限背景關系：代表一個系統、一個應用程式或者一種業務服務，限界背景關系所包含的領域模型概念應該恰如其分，不多也不少，
通用語言：作用于某個“限界背景關系”，在一個特定的限界背景關系中只使用一套通用語言，并且保證它的清晰性（避免一個概念在同一個界限背景關系中的二義性）和簡潔性，舉個例子：像京東和天貓這樣的B2C系統中會用到系統的人有2種，買家和賣家，對于系統來說都可以稱為用戶，但是這樣破壞了清晰性的特點，如果使用一個類似Type的列舉來區分，破壞了簡潔性，所以對于這種場景，就應該直接設計2個物件：買家和賣家，
領域：從大了看，領域代表整個公司的運作一切，從小了看，是每個組織運作中的一切，所以領域的概念必然與公司的組織架構所承擔的職責有一定的關系，
子域：一個領域內可以包含1個或者多個子域，理論上一個子域對應一個限界背景關系是最優也是最理想的情況，但是有時又要考慮到業務關聯度需要做出權衡，子域又分核心域、支撐子域、通用子域，
核心域：它是整個業務領域的一部分，也是業務成功的主要促成因素，從戰略層面上講，企業應該在核心域上勝人一籌，我們應該給予核心域最高的優先級、最資深的領域專家和最優秀的開發團隊，在實施DDD的程序中將主要關注核心域，
支撐子域：對應著業務的某些重要方面，但卻不是核心，那么它便是一個支撐子域，
通用子域：某個支撐子域的運用范圍是整個系統，那么這個子域便是通用子域，
背景關系映射圖：由多個界限背景關系和子域組成的表示當前單個領域或者多個領域之間的集成關系圖，
三、實施DDD的關鍵
我認為實施DDD最最最關鍵的東西有2樣，
一是“通用語言”，沒有基于通用語言建立的所謂的聚合，物體，值物件，只能算是DDDLite，只是技術層面的一種設計方式，
二是“建模”，建模又分為戰略建模和戰術建模，這2者相輔相成，來構建合理的背景關系映射圖，
①戰略建模：戰略建模是以一種最宏觀的角度去審視整個專案對它進行拆分，來劃分“界限背景關系”，最終形成一個具有俯瞰視角的“背景關系映射圖”，
②戰術建模：在我們戰略建模劃出的“界限背景關系”中進行“聚合”、“物體”、“值物件”的建模，并且按模塊分組，
四、如何構建一個領域的背景關系映射圖
對于如何構建一個背景關系映射圖，分為思想和操作2個層面，
首先思想層面需要引入2個空間的概念：問題空間和解決方案空間，
在問題空間中，我們思考的是業務所面臨的挑戰，而在解決方案空間中，我們思考如何實作軟體以解決這些業務挑戰，
評估問題空間和解決方案空間的問題：
①這個戰略核心域的名字是什么，它的目標是什么？
②這個戰略核心域中包含哪些概念？
③這個核心域的支撐子域和通用子域是什么？
其次操作層面就是[Vaughn Vernon]《實作領域驅動設計》里提到的9種組織模式和集成模式，
①合作關系（Partnership）：如果2個限界背景關系的團隊要么一起成功，要么一起失敗，此時就是這種關系，應該為相互關聯的軟體功能制定好計劃表，這樣可以確保這些功能在同一個發布中完成，
②共享內核（Shared Kernel）：對模型和代碼的共享將產生一種緊密的依賴性，對于設計來說，這種依賴性可好可壞，我們需要為共享的部分模型指定一個顯式邊界，并保持共享內核的小型化，共享內核具有特殊的狀態，在沒有與另一個團隊協商的情況下，這種狀態是不能改變的，我們應該引入一種持續集成程序來保證共享內核與通用語言的一致性，【簡單的說就是資料庫共享】
③客戶方——供應方（Customer-Supplier Development）：當2個團隊處于一種上游——下游關系時，上游團隊可能獨立于下游團隊完成開發，此時下游團隊的開發可能會受到很大的影響，因此，在上游團隊的計劃中，我們應該顧及到下游團隊的需求，
④遵奉者（Conformist）：在存在上游——下游關系的2個團隊中，如果上游團隊已經沒有動力提供下游團隊之需，下游團隊便孤軍無助了，處于利他主義，上游團隊可能向下游團隊做出種種承諾，但是有很大的可能是：這些承諾是無法實作的，下游團隊只能盲目地使用上游團隊模型，
⑤防腐層（Anticorruption Layer）：在集成2個設計良好的限界背景關系時，翻譯層可能很簡單，甚至可以很優雅的實作，但是，當共享內核，合作關系或客戶方——供應方關系無法順利實作時，此時的翻譯將變得復雜，對于下游客戶來說，你需要根據自己的領域模型創建一個單獨的層，該層作為上游系統的委派向你的系統提供功能，防腐層通過已有的介面與其他系統互動，而其他系統只需要做很小的修改，甚至無需修改，在防腐層內部，它在你自己的模型和他方模型之間進行翻譯轉換，【為每個防腐層定義相應的領域服務】
⑥開放主機服務（Open Host Service）：定義一種協議，讓你的子系統通過該協議來訪問你的服務，并且需要將協議公開，
⑦發布語言（Published Language）：在2個限界背景關系之間翻譯模型需要一種公用的語言，此時你應該使用一種發布出來的共享語言來完成集成交流，發布語言通常與開放主機服務一起使用，
⑧另謀他路（SeparateWay）：在確定需求時，我們應該做到堅持徹底，如果2套功能沒有顯著的關系，那么它們是可以被完全解耦的，集成總是昂貴的，有時帶給你的好處也不大，宣告2個限界背景關系之間不存在任何關系，這樣使得開發者去另外尋找簡單的、專門的方法來解決問題，
⑨大泥球（Big Ball of Mud）：當我們檢查已有系統時，經常會發現系統中存在混雜在一起的模型，它們之間的邊界是非常模糊的，此時你應該為整個系統繪制一個邊界，然后將其歸納在大泥球范圍之列，在這個邊界內，不要試圖使用復雜的建模手段來化解問題，同時，這樣的系統有可能會向其他系統蔓延，應該對此保持警覺，
五、構建我們的背景關系映射圖
本次的系列的主題是電商網站，那么現在開始構建一個電商網站的背景關系映射圖，
①這個戰略核心域的名字是什么，它的目標是什么？
銷售核心域，目標是賣更多的商品，獲取更多的利潤，這點是整個組織的共同目標，所以應該很容易界定，并且應該是在整個組織中能最終夠達成一致的某個觀點，如圖1，
圖1
②這個戰略核心域中包含哪些概念？
我一般會使用“劃分”，“組合”，“梳理”的3步走方式去做，先根據我們對這個領域的理解進行劃分出各個背景關系，然后重新審視每個背景關系在銷售這個領域中的定位來“圈地（劃分子域）”，最后再思考是否能夠完全體現出每個子域的功能和職責，我的思路是這樣的，先根據我自己的經驗得出了圖2，
圖2
我思考了一下，整個銷售程序中，訂單只是一個結果，一旦到達這個環節，其實銷售的作業已經結束了，那么訂單的相關業務其實不應該屬于銷售的子域內，所以把它拿出去，變為圖3這個樣子，
圖3
然后看了一下全圖，銷售背景關系的概念太泛，無法得知其中應該干什么，怎么去銷售，有哪些影響銷售概念，我又做了拆分，如下圖4，
圖4
到這里幾個核心域內包含的概念已經出來了：價格體系（促銷、會員價）、銷售方式（打包、捆綁贈品）、內容管理、購買，這其中最核心的又是購買，
③這個核心域的支撐子域和通用子域是什么？
這里開始我們需要對我們整理出的各個背景關系和子域結合起來，并且根據9種組織模式和集成模式表達出各背景關系之間的關系，如下圖5，
圖5
這里的U和D分別代表UpStream和DownStream，表達出上下游關系，并且圖的位置也需要看出這點，另外OHS+PL = Open Host Service+Published Language，ACL = Anticorruption Layer，
發現這里的5個子域中，訂單和物流子域分別承擔著2個子域的下游支撐作用，那么成為了通用子域，
最終這個問題的結果為商品子域[支撐]、會員子域[支撐]、支付子域[支撐]、訂單子域[通用]、物流子域[通用]，
最后再考慮到一些非必須的輔助性概念，資料分析系統和預測系統，形成我們的最終背景關系映射圖，
圖6
六、結語
以上的每個環節都應該盡可能有領域專家參與，這樣才能得出最符合實際的背景關系映射圖，
DDD之路不好走，并且從短期的表面來看，需要花費的時間和精力會比我們常規的資料驅動開發方式看上去多的多，
但是從溝通的便捷性、理解的錯誤率、代碼的可維護性來看，DDD能夠讓對專案的把控更上一個層級，并且為了應對互聯網行業的快速變化，我們得到的遠比我們付出的多的多，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/1058.html
標籤：領域驅動設計
上一篇：DDD領域驅動的前生今世