如何一步一步用DDD設計一個電商網站（一）—— 先理解核心概念
文章內容
一、前言
DDD（領域驅動設計）的一些介紹網上資料很多，這裡就不繼續描述了。自己使用領域驅動設計摸滾打爬也有2年多的時間，出於對知識的總結和分享，也是對自我理解的一個公開檢驗，介於部落格園這個平臺也算是對DDD的推廣盡了一份綿薄之力。一開始接觸這個東西是在2014年，真的覺得像是發現了一片新大陸一般，對我整個程式開發視野有了新的理解，但是像[Vaughn Vernon]《實現領域驅動設計》裡寫的那樣，景色雖好，可是自己很長一段時間內很混亂，理不清眼前的陌生世界，因為它與傳統的觀念完全不同。我相信大部分同學剛接觸DDD的時候也會有一樣的感覺。
這次開始寫這系列，也希望有越來越多的人能夠加入到DDD的佇列中，在我之前，園子裡的netfocus、
本次系列中多處引用[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。
②這個戰略核心域中包含哪些概念？
我一般會使用“劃分”，“組合”，“梳理”的3步走方式去做。先根據我們對這個領域的理解進行劃分出各個上下文，然後重新審視每個上下文在銷售這個領域中的定位來“圈地（劃分子域）”，最後再思考是否能夠完全體現出每個子域的功能和職責。我的思路是這樣的，先根據我自己的經驗得出了圖2。
我思考了一下，整個銷售過程中，訂單只是一個結果，一旦到達這個環節，其實銷售的工作已經結束了，那麼訂單的相關業務其實不應該屬於銷售的子域內，所以把它拿出去，變為圖3這個樣子。
然後看了一下全圖，銷售上下文的概念太泛，無法得知其中應該幹什麼，怎麼去銷售，有哪些影響銷售概念，我又做了拆分。如下圖4。
到這裡幾個核心域內包含的概念已經出來了：價格體系（促銷、會員價）、銷售方式（打包、捆綁贈品）、內容管理、購買。這其中最核心的又是購買。
③這個核心域的支撐子域和通用子域是什麼？
這裡開始我們需要對我們整理出的各個上下文和子域結合起來，並且根據9種組織模式和整合模式表達出各上下文之間的關係。如下圖5。
這裡的U和D分別代表UpStream和DownStream，表達出上下游關係，並且圖的位置也需要看出這點。另外OHS+PL = Open Host Service+Published Language，ACL = Anticorruption Layer。
發現這裡的5個子域中，訂單和物流子域分別承擔著2個子域的下游支撐作用，那麼成為了通用子域。
最終這個問題的結果為商品子域[支撐]、會員子域[支撐]、支付子域[支撐]、訂單子域[通用]、物流子域[通用]。
最後再考慮到一些非必須的輔助性概念，資料分析系統和預測系統，形成我們的最終上下文對映圖。
六、結語
以上的每個環節都應該儘可能有領域專家參與，這樣才能得出最符合實際的上下文對映圖。DDD之路不好走，並且從短期的表面來看，需要花費的時間和精力會比我們常規的資料驅動開發方式看上去多的多。但是從溝通的便捷性、理解的錯誤率、程式碼的可維護性來看，DDD能夠讓對專案的把控更上一個層級。並且為了應對網際網路行業的快速變化，我們得到的遠比我們付出的多的多。
原文連結
http://www.cnblogs.com/Zachary-Fan/p/5991674.html