上一篇學習了基本概念，對DDD有了一個整體的把控，那麼，這一篇就是對戰略建模進行介紹了，首先什麼是戰略，戰略，是一種從全域性考慮謀劃實現全域性目標的規劃，戰術只為實現戰略的手段之一。實現戰略勝利，往往有時候要犧牲部分利益，去獲得戰略勝利。戰略是一種長遠的規劃，是遠大的目標，往往規劃戰略、制定戰略、用於實現戰略的目標的時間是比較長的。爭一時之長短，用戰術就可以達到！如果是“爭一世之雌雄”，就需要從全域性出發去規劃，這就是戰略！以上內容來自百度。總而言之，戰略是大框架，大方向，如果架子搭錯了，方向走錯了，戰術再犀利，也沒有什麼作用。那麼對於DDD來說，戰略的實現主要有以下兩個方面：1，限界上下文，2，上下文對映

該圖片詳細表明瞭在戰略建模的時候各方面需要做的事情，核心所在就是解決問題空間，說白了就是，限界上下文的圈定和上下文對映的方式。接下里詳述這兩方面的內容

限界上下文（Bounded Context）

定義

它是一個限定邊界的環境，在該環境中，每一個模型的概念（包括它的屬性和操作）都具有特殊的含義。它是戰略建模的核心。 換句話說，在每一個限界上下文裡都共用且只有一套通用語言，不存在二義性。

概念解析

學習自《實現領域驅動設計》

與子域最好一對一

一般一個限界上下文對應一個子域。另外一個限界上下文有可能包含的不只一個子域。

分階段建立上下文

如一個圖書出版系統，圖書生命週期的不同階段（不同的上下文環境）
概念設計，計劃出書
聯絡作者，簽訂合同
管理圖書的編輯過程
將圖書翻譯成其他語言
出版紙質版或電子版圖書
市場營銷
將圖書賣給銷售商或直接賣給讀者
將圖書傳送給銷售商或讀者
以上所有階段，我們用一個單一的概念對圖書建模顯然不行，每個階段“圖書都有不同的定義”。一本書只有和作者簽訂了合同之後才能擁有書名，而書名可能在編輯過程進行修改。在編輯過程中，圖書包含了一系列的稿件，其中包括註釋和校正，走到最終定稿。圖書印刷方使用頁面佈局和封面板式印製圖書。營銷員不需要編輯和印製，只需要圖書的簡介，圖書售後物流，勻人需要圖書的標識碼、物流目的地、數目、尺寸和重量等。
如果我們用單一模型來處理所有這些階段會發生什麼？概念混淆、意見分歧和爭論是不可避免的。即使有時可能會得到一個正確的公共模型，但這種模型並不具有永續性。
為解決這個問題，
我們應該為每個階段建立各自的限界上下文，在每個限界上下文 ，都存在某種型別的圖書。在所有的上下文中，不同型別的圖書物件將共享一個身份標識，這個標識可能是在概念設計階段建立的。然而，不同上下文中的圖書模型卻是不同的。

不僅限於包含模型

限界上下文不僅僅只包含模型。雖然領域模型是限界上下文的主要“公民”。但是限界上下文並不只侷限於容納模型，它通常標定一個系統、一個應該程式或一種業務服務（表示一系統用於實現業務用例的複雜元件）。有時，限界上下文所包含的內容可能比較少，比如，一個通用子域便可以只包含領域模型。舉例來說， 當模型驅動著資料庫Schema時，此時的Schema也應該位於該模型所處的上下文邊界之內。換言之，資料庫中表和列名字應該和模型的名字保持一致。模型應該用來驅動資料庫和使用者介面的設計，而不是反向驅動。

不要隨意拆分上下文

不要為了分配任務而拆分限界上下文。我們沒有必要為了管理技術資源而建立一些假的上下文邊界。

使用語言驅動

採用語言驅動來實施DDD，這裡底線：如果沒有采用語言驅動，那麼你就不算在和領域專家一起工作來建立限界上下文。

認真設計大小，不要急於小型化

認真考慮限界上下文的大小，不要急於將其小型化。

與技術元件保持一致

與技術元件保持一致。技術元件並不能定義限界上下文。一個限界上下文通常就一個工程專案。VS中在同一個解決方案中將使用者介面、應用服務和領域物件分離在不同的子專案中是合理的。專案原始碼可以只包含領域模型，也可以包含一些周邊的層或六邊形區域。

上下文對映圖（Context Mapping）

基本概念

上下文對映圖（Context Map）：可以進行拆分理解，上下文指的就是限界上下文，對映的意思就是關聯、聯絡，就像 ORM 中，物件與關係的對映，圖就是把限界上下文之間的關聯與聯絡表現出來，具體的展示就是類似上面的圖。

上游與下游的概念，上游是服務提供者，下游是服務接收者

上下文對映圖主要幫助我們從解決方案空間的角度看待問題。

九大關係

基本有九個定義，也可以理解為九種關係

• 合作關係（Partnership）：如果兩個限界上下文的團隊要麼一起成功，要麼一起失敗，要麼一起成功，此時他們需要建立起一種合作關係。他們需要一起協調開發計劃和整合管理。兩個團隊應該在介面的演化上進行合作以同時滿足兩個系統的需求。應該為相互關聯的軟體功能定製好計劃表，這樣可以確保這些功能在同一個釋出中完成。

• 共享核心（Shared Kernel）：對模型和程式碼的共享將產生一種緊密的依賴性，對於設計來說，這種依賴性可好可壞。我們需要為共享的部分模型指定一個顯式的邊界，並保持共享核心的小型化。共享核心具有特殊的狀態，在沒有與另一個團隊協商的情況下，這種狀態是不可改變的。我們應該引入一種持續整合過程來保證共享核心和通用語言的一致性。

• 客戶方－供應方開發（Customer-Supplier Development）：當兩個團隊處於一種上游－下游關係時，上游團隊可能獨立於下游團隊完成開發，此時下游團隊的開發可能會受到很大的影響。因此，在上游團隊的計劃中，我們應該顧及到下游團隊的需求。記住：上游是服務提供者，下游是服務使用者

• 遵奉者（Confoemist）：在存在上游－下游的關係的兩個團隊中，如果上游團隊已經沒有動力提供下游團隊之所需，下游團隊便孤立無援了。出於利於他主義，上游團隊可能向下遊團隊做出種種承諾，但是有很大的可能是：這些承諾是無法實現的。下游團隊只能盲目的使用上游團隊的模型。

• 防腐層（Anticorruption Layer）：在整合兩個設計良好的限界上下文時，翻譯層可能很簡單，甚至可能很優雅的實現。但是，當共享核心、合作關係或客戶方－供應方關係無法順利實現時，此時的翻譯將變得複雜。對於下游客戶來說，你需要根據自己的領域模型建立一個單獨的層，該層作為上游系統的委派向你的系統提供功能。防腐層通過已有的介面與其他系統互動，而其他系統只需要做很小的修改，甚至無須修改。在防腐層內部，它在你自己的模型和他方模型之間翻譯轉換。

• 開放主機服務（Open Host Service）：定義一種協議，讓你的子系統通過該協議來訪問你的服務。你需要將該協議公開，這樣任何想與你整合的人都可以使用該協議。在有新的整合需求時，你應該對協議進行改進或擴充套件。對於一些特殊的需求，你可以採用一次性的翻譯予以處理，這樣可以保持協議的簡單性和連貫性。

• 釋出語言（Published Language）：在兩個限界上下文之間翻譯模型需要一種公用的語言。此時你應該使用一種釋出出來的共享語言來完成整合交流。釋出語言通常與開放主機服務一起使用。

• 另謀他路（SpeparateWay）：在確定需求時，我們應該做到堅決徹底。如果兩套功能沒有顯著的關係，那麼它們是可以被完全解耦的。整合總是昂貴的，有時帶給你的好處也不大。宣告兩個限界上下文之間不存在任何關係，這樣使得開發者去另外尋找簡單的、專門的方法來解決問題。

• 大泥球（Big Ball of Mud）：當我們檢查已有系統時，經常會發現系統中存在混雜在一起的模型，它們之間的邊界是非常模糊的。此時你應該為整個系統繪製一個邊界，然後將其歸納在大泥球範圍之列。在這個邊界之內，不要嘗試使用複雜的建模手段來化解問題。同時，這樣的系統有可能會向其他系統蔓延，你應該對此保持警覺。大泥球其實是一種解決方案，不讓混亂蔓延，同時遮蔽混亂

其中ACL表示防腐層，OHS表示開放主機服務，PL表示 釋出語言。

繪製上下文對映圖

初步繪製

明確需要創作協作上下文，同時需要建立第二個限界上下文，但不知道如何將此上下文從核心域分離

分離子域

在對子域分析和問題空間評估後，從一個限界上下文中分離出了兩個子域，由於子域和限界上下文最好是一對一的關係，我們應該將原先的協作上下文分離成兩個限界上下文

分離核心

由於角色的分離，有必要進行核心的分離

最終版本

最終版本確定了三個上下文之間的關係

上圖可以看出，核心的敏捷專案管理位於下游，也就是表示核心模型位於其他系統的下游，上游模型會對下游模型產生影響，不論是積極的還是消極的。

技術要點

開放主機服務

該模式可以通過REST來實現，通常來講，可以將開放主機服務看成是遠端過程呼叫API，同時，它也可以通過訊息機制實現。

釋出語言

實現方式有多種，釋出語言可以有多種實現方式，最常用的就是XML和Schema

1，在使用REST服務時，釋出語言用來表示領域概念，此時可以使用XML和JSON。

2，如果你打算髮布web介面，也可以使用HTML。

3，同時釋出語言還可以用於事件驅動框架，領域事件以訊息的形式傳送給訂閱方

防腐層

在下游上下文中，我們可以為每個防腐層定義相應的領域服務。同時你可以將防腐層用於資源庫介面。

1，在使用REST時，客戶端的領域服務將訪問遠端的開放主機服務

2，遠端伺服器以釋出語言的形式返回

3，下游的防腐層將返回的內容翻譯成本地上下文的領域物件。

比如，協作上下文向身份與訪問上下文請求“具有Moderator角色的使用者”。所返回的資料可能是XML格式或者JSON格式，然後防腐層將這些資料翻譯成協作上下文中的Moderator物件，該物件是一個值物件。之歌Moderator例項反映的是下游模型中的概念，而不是上游模型。

如何自治

非自治

接上邊的例子，協作上下文向身份與訪問上下文請求“具有Moderator角色的使用者”。

這裡的請求是同步的，如果遠端系統不可用，那麼本地系統也將跟著失敗，REST通常與RPC相似，徹底的失敗並不多見，但仍然是潛在問題。

實現自治

為了達到比RPC更高的自治性，採用如下兩種措施

1，選擇使用非同步請求，或者事件處理的方式

2，如果系統所以來的狀態已經存在於本地，那麼我們將獲得更大的自治性，但這裡我們DDD不會採用對依賴物件快取的方式，而是：在本地建立一些由外部模型翻譯而成的領域物件，這些物件保留著本地模型所需的最小狀態集。為了初始化這些物件，我們只需有限的進行RPC呼叫或者REST請求。然而，要與遠端模型保持同步，最好的方式時在遠端系統中採用面向訊息的通知機制，訊息可以通過服務匯流排進行釋出，也可以採用訊息佇列或者REST

敏捷專案管理上下文和身份與訪問上下文整合時的對映

在該種自治機制下:

1, MemberService是一個領域服務，它向本地模型提供ProductOwner和TeamOwner物件，同時作為防腐層的介面

2,mantainService（）方法用於週期性的檢查身份與訪問上下文所發出的通知。該方法不由模型的正常客戶呼叫，而是由通知元件週期性呼叫。如下圖的MemberSynchronizer表示這樣的通知元件，他會把請求委派給MemberService.

3,MemberService.會進一步把請求委派給IdentityAccesssNotificationAdapter,該類在領域服務和遠端的開發逐句服務之間扮演介面卡的角色，該介面卡作為遠端系統的客戶端而存在

4，一旦介面卡從遠端開放逐句服務獲得了資料，它將呼叫MemberTranslator的toMember（）方法將釋出語言中的媒體資料翻譯成本地系統的領域物件Member.如果該物件已存在，則更新之。

敏捷專案管理上下文和協作上下文整合時的對映