上一篇：《IDDD 實現領域驅動設計－理解限界上下文》
距離上一篇有幾天時間了，《實現領域驅動設計》第三章的內容都是圍繞一個詞－上下文映射圖，我大概斷斷續續看了幾天，總共看了兩遍，但模模糊糊也不是很理解，不像前兩章有一個可以觸動我的地方，但有很多概念是蠻重要的，這篇沒有自己的理解，大部分都是整理上下文映射圖及其相關概念。
可以看作是示例上下文，大家在畫上下文映射圖的時候可以參照一下，后面的大部分概念，也都圍繞它展開。
-
上下文映射圖（Context Map）：可以進行拆分理解，上下文指的就是限界上下文，映射的意思就是關聯、聯系，就像 ORM 中，對象與關系的映射，圖就是把限界上下文之間的關聯與聯系表現出來，具體的展示就是類似上面的圖。
-
合作關系（Partnership）：如果兩個限界上下文的團隊要么一起成功，要么一起失敗，要么一起成功，此時他們需要建立起一種合作關系。他們需要一起協調開發計划和集成管理。兩個團隊應該在接口的演化上進行合作以同時滿足兩個系統的需求。應該為相互關聯的軟件功能定制好計划表，這樣可以確保這些功能在同一個發布中完成。
-
共享內核（Shared Kernel）：對模型和代碼的共享將產生一種緊密的依賴性，對於設計來說，這種依賴性可好可壞。我們需要為共享的部分模型指定一個顯式的邊界，並保持共享內核的小型化。共享內核具有特殊的狀態，在沒有與另一個團隊協商的情況下，這種狀態是不可改變的。我們應該引入一種持續集成過程來保證共享內核和通用語言的一致性。
-
客戶方－供應方開發（Customer-Supplier Development）：當兩個團隊處於一種上游－下游關系時，上游團隊可能獨立於下游團隊完成開發，此時下游團隊的開發可能會受到很大的影響。因此，在上游團隊的計划中，我們應該顧及到下游團隊的需求。
-
遵奉者（Confoemist）：在存在上游－下游的關系的兩個團隊中，如果上游團隊已經沒有動力提供下游團隊之所需，下游團隊便孤立無援了。出於利於他主義，上游團隊可能向下游團隊做出種種承諾，但是有很大的可能是：這些承諾是無法實現的。下游團隊職能盲目的使用上游團隊的模型。
-
防腐層（Anticorruption Layer）：在集成兩個設計良好的限界上下文時，翻譯層可能很簡單，甚至可能很優雅的實現。但是，當共享內核、合作關系或客戶方－供應方關系無法順利實現時，此時的翻譯將變得復雜。對於下游客戶來說，你需要根據自己的領域模型創建一個單獨的層，該層作為上游系統的委派向你的系統提供功能。防腐層通過已有的接口與其他系統交互，而其他系統只需要做很小的修改，甚至無須修改。在防腐層內部，它在你自己的模型和他方模型之間翻譯轉換。
-
開放主機服務（Open Host Service）：定義一種協議，讓你的子系統通過該協議來訪問你的服務。你需要講該協議公開，這樣任何想與你集成的人都可以使用該協議。在有新的集成需求時，你應該對協議進行改進或擴展。對於一些特殊的需求，你可以采用一次性的翻譯予以處理，這樣可以保持協議的簡單性和連貫性。
-
發布語言（Published Language）：在兩個限界上下文之間翻譯模型需要一種公用的語言。此時你應該使用一種發布出來的共享語言來完成集成交流。發布語言通常與開放主機服務一起使用。
-
另謀他路（SpeparateWay）：在確定需求時，我們應該做到堅決徹底。如果兩套功能沒有顯著的關系，那么它們是可以被完全解耦的。集成總是昂貴的，有時帶給你的好處也不大。聲明兩個限界上下文之間不存在任何關系，這樣使得開發者去另外尋找簡單的、專門的方法來解決問題。
-
大泥球（Big Ball of Mud）：當我們檢查已有系統時，經常會發現系統中存在混雜在一起的模型，它們之間的邊界是非常模糊的。此時你應該為整個系統繪制一個邊界，然后將其歸納在大泥球范圍之列。在這個邊界之內，不要嘗試使用復雜的建模手段來化解問題。同時，這樣的系統有可能會向其他系統蔓延，你應該對此保持警覺。