IDDD 實作領域驅動設計－上下文映射圖及其相關概念

距離上一篇有幾天時間了，《實作領域驅動設計》第三章的内容都是圍繞一個詞－上下文映射圖，我大概斷斷續續看了幾天，總共看了兩遍，但模模糊糊也不是很了解，不像前兩章有一個可以觸動我的地方，但有很多概念是蠻重要的，這篇沒有自己的了解，大部分都是整理上下文映射圖及其相關概念。

可以看作是示例上下文，大家在畫上下文映射圖的時候可以參照一下，後面的大部分概念，也都圍繞它展開。

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

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

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

客戶方－供應方開發（Customer-Supplier Development）：當兩個團隊處于一種上遊－下遊關系時，上遊團隊可能獨立于下遊團隊完成開發，此時下遊團隊的開發可能會受到很大的影響。是以，在上遊團隊的計劃中，我們應該顧及到下遊團隊的需求。

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

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

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

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

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

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

本文轉自田園裡的蟋蟀部落格園部落格，原文連結：http://www.cnblogs.com/xishuai/p/iddd-context-map.html，如需轉載請自行聯系原作者