DDD（領域驅動設計）--戰略設計

領域

領域是一個組織所作的事情以及其中所包含的一切。商業機構一般會肯定一個市場，而後在這個市場中銷售產品和服務。每一個組織都有它本身的業務範圍和作事方式。
領域就是解決一個特定範圍內的業務問題。

如何分析領域

在研究與建模的過程當中，開發人員是不能孤軍奮戰的，這個時候須要找領域專家一塊兒建模，領域專家是精通業務的任何人，他們多是軟件產品的設計者，甚至有多是銷售。
領域專家把他的知識傳給開發者，讓建模更符合實際業務狀況，以此也能得到更好的用戶體驗。

子域

分而治之，DDD是一套處理複雜領域的設計方法。
當咱們遇到一個複雜的問題時，一般的作法就是將問題一步一步地細化，再針對細化出來的問題域逐個深刻研究。當全部的子問題都完成研究時，咱們也就創建了所有領域的完整知識。
子域是整個業務領域的一部分，大多數的業務領域都過於龐大和複雜，難以做爲總體來分析，所以須要對整個業務領域進行拆分。

子域劃分

• 核心域：它是一個定義明確的領域模型，須要投入大量資源去精心打磨的子域。它是組織中最重要的模塊，由於這將是和其餘競爭者的區別所在，須要把這個核心域打形成爲組織的核心競爭力。
• 支撐域：這類子域，可能找不到現成的解決方案，對它的投入如何也達不到與核心域相同的程度。但核心域的成功離不開支撐域。這個子域不須要過分地考慮可擴展性和兼容性，若是要考慮的，應該是可替代性。這也就要求支撐子域須要有明確的契約規範和業務約束條件。這種子域通常提倡「定製開發」。
• 通用域：通用子域內的業務規則相對明確，通常解決方案能夠經過採購獲取，對其定製化要求比較低，而穩定性和兼容性則要求較高。

現實世界中領域與子域

領域中還同時存在問題空間和解決空間。在問題空間中，咱們思考的是業務所面臨的挑戰，而在解決方案空間中，咱們思考如何實現軟件以解決這些業務挑戰。

通用語言（Ubiquitous Language）

平常開發過程當中，你們應該都有這種感覺，在和產品經理、運營等交流過程當中，常常會有各類扯皮，無法溝通的時候，很大一部分緣由就是你們溝通的時候，用詞含義不一致致使的。
要想建立一種靈活的、蘊含豐富知識的設計，須要一種通用的、共享的團隊語言。若是語言支離破碎，項目必將受阻，實現過程當中可能得不到符合要求的產品。
因此咱們須要有一套通用語言，領域專家、產品、開發、運營等通用的語言，須要包括類和主要操做的名稱。並將這些通用語言應用到需求討論、技術方案設計、圖和代碼中。

限界上下文（Bounded Context）

生物學中，咱們知道，細胞之因此可以存在，是由於細胞膜限定了什麼在細胞內，什麼在細胞外，而且肯定了什麼物質能夠經過細胞膜。
軟件系統中也是同樣，咱們須要有一個限界上下文，明確地定義模型所應用的上下文，根據團隊的組織，軟件系統的各個部分的用法以及物理表現（代碼合數據庫模式）來設置模型的邊界。在這些邊界中嚴格保持模型的一致性，而不要受到邊界以外問題的干擾和混淆。

限界上下文是一個顯式的邊界，領域模型變存在於這個邊界以內。每個模型概念，包括它的屬性和操做，在邊界以內都具備特殊的含義。

在現實世界中，領域的邊界很模糊，可是要設計一個好的解決方案，咱們須要對問題子域加上一個邊界，將不重要的信息排除在邊界外。讓解決方案專心解決重點問題。

每一個上下文都表明着該解決方案的專業知識。在同一個上下文裏，咱們共享統一的語言和一致的設計。
經過界限上下文人爲將問題子域限制在有限的界限內，你才能夠着手建立解決方案。

上下文映射（Context Mapping）

每一個限界上下文不可能獨立存在，基本都須要與其餘上下文進行集成，上下文映射是爲了用來描述限界上下文之間的協做問題。這種集成關係在DDD中成爲上下文映射，有以下幾種映射方式。

合做關係（Partnership）：若是兩個限界上下文的團隊要麼一塊兒成功，要麼一塊兒失敗，要麼一塊兒成功，此時他們須要創建起一種合做關係。合做越多依賴越多，耦合越嚴重，甚至出現雙向依賴。

共享內核（Shared Kernel）：當不一樣團隊開發一些緊密相關的應用時，若是團隊直接不進行協調，即便短期可以取得快速進展，但他們開發出來的產品可能沒法結合到一塊兒。最後可能不得不耗費大量精力在轉換層上，而且頻繁地進行改動，不如一開始就從領域模型中選出兩個團隊都贊成共享的一個子集，減小重複的工做。這種模式下，在沒有與另外一個團隊協商的狀況下，這種狀態是不可改變的，同時須要引入一種持續集成過程來保證共享內核與通用語言的一致性。

客戶方－供應方開發（Customer-Supplier Development）：正常狀況下，這是團隊合做中最爲常見的合做模式。當兩個團隊處於一種上游－下游關係時，上游團隊可能獨立於下游團隊完成開發，此時下游團隊的開發可能會受到很大的影響。所以，在上游團隊的計劃中，咱們應該顧及到下游團隊的需求。

遵奉者/追隨者（Confoemist）：下游團隊直接使用上游團隊的模型，簡化集成。

防腐層（Anticorruption Layer）：防腐層經過已有的接口與其餘系統交互，而其餘系統只須要作很小的修改，甚至無須修改。在防腐層內部，它在你本身的模型和他方模型之間翻譯轉換。

開放主機服務（Open Host Service）：定義一種協議，讓你的子系統經過該協議來訪問你的服務。你須要講該協議公開，這樣任何想與你集成的人均可以使用該協議。

發佈語言（Published Language）：在兩個限界上下文之間翻譯模型須要一種公用的語言。此時你應該使用一種發佈出來的共享語言來完成集成交流。發佈語言一般與開放主機服務一塊兒使用。

另謀他路/各行其道（SpeparateWay）：在肯定需求時，咱們應該作到堅定完全。若是兩套功能沒有顯著的關係，那麼它們是能夠被徹底解耦的。集成老是昂貴的，有時帶給你的好處也不大。聲明兩個限界上下文之間不存在任何關係，這樣使得開發者去另外尋找簡單的、專門的方法來解決問題。

大泥球（Big Ball of Mud）：當咱們檢查已有系統時，常常會發現系統中存在混雜在一塊兒的模型，它們之間的邊界是很是模糊的。此時你應該爲整個系統繪製一個邊界，而後將其概括在大泥球範圍之列。在這個邊界以內，不要嘗試使用複雜的建模手段來化解問題。同時，這樣的系統有可能會向其餘系統蔓延，你應該對此保持警覺。

參考資料

• 《領域驅動設計——軟件核心複雜性應對之道》
• 《實現領域驅動設計》
• DDD戰略設計相關核心概念的理解
• 上下文映射與協做
• ThoughtWorks洞見-再談領域驅動設計
• context-mapping