一個項目的上下文映射圖可以用方式來表示。比較容易的一種是畫一個簡單的框圖表示兩個或多個限界上下文之間的映射關系。該框圖表示了不同的限界上下文在解決方案空間中是如何通過集成相互關聯的。另一種更詳細的方式是通過限界上下文集成的源代碼實現來表示。

　　上下文映射圖為什么重要

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

　　

　　假定你期望大泥球維護團隊提供一套新的API。然而，他們卻并不打算這么做，或者他們根本就不知道你的想法。此時你的團隊和大泥球維護團隊的關系變成了?客戶方-供應方?的關系。由于大泥球團隊決定維持現狀，你的團隊不得不陷入一種遵奉著關系中。這樣的關系可能導致你的項目延期交付或者徹底失敗。

　　盡早繪制上下文映射圖，這樣可以迫使你仔細思考你的項目和你所依賴項目之間的關系。

　　繪制上下文映射圖

　　上下文映射圖表現的是項目當前的狀態，如果項目會在將來發生改變，你可以到那時才對上下文映射圖做出相應的更新。關注于當前的項目狀態可以幫助你了解你正處的位置，并幫助你決定如何走出下一步。

　　繪制一個上下文映射圖并不復雜。通常，首選在白板上手繪映射圖，此時你可以采用 [Brandolini] 的風格。如果你打算使用一個繪圖工具來繪制上下文映射圖，請注意不要把圖畫得太正式了。

　　上圖3.1中，圖中限界上下文的名字和彼此之間的集成關系只是占位符而已，在真實的上下文映射圖中，我們將代之以實際的名字。

　　有時，我們希望對上下文映射圖的某些特定部分進行放大，以向里面加入更多的細節，這只是從另外一個角度來看待同一個限界上下文。除了邊界、關系和翻譯，我們可以可能希望加入其他的一些內容，比如模塊、聚合，或者團隊的分布信息等。

　　所繪制的所有映射圖，包括文字，都可以裝訂在同一份參考文檔中，只要這對團隊是有價值的。在這個過程中，我們應該避免那些繁文縟節性的儀式，保持簡單和敏捷。向框圖中加入過多的細節對團隊并無多大幫助，交流才是關鍵，我們應該將交流對話也加入到上下文映射圖中。

　　

　　上下文映射圖并不是一種企業架構，也不是系統拓撲圖。但是，它可以用于高層次的架構分析，指出諸如集成瓶頸之類的架構不足。上下文映射圖展現了一種組織動態能力，它可以幫助我們識別出有礙項目進展的一些管理問題。

　　并不是說限界上下文邊界一定得密不透風，而是：對于任何上下文邊界，開發團隊都希望協作上下文能夠完全地控制所進所出，還包括進出的原因。否則，該上下文便會出現一些不受歡迎的“拜訪者”。對于模型而言，這些“拜訪者”通常會導致混淆和BUG。建模人員應該是友好的，但是友好的前提是秩序與和諧。任何進入邊界的外部概念都應該持有充分的理由，甚至需要和邊界內的模型保持良好的兼容性。

　　在理解充分的情況下，要繪制上下文映射圖并不難，但是通常來說，我們并不會將映射圖中的所有內容都顯示出來。在迭代過程中，思考和討論可以幫助我們改進上下文映射圖，比如對集成點進行改進，這將有助于描述限界上下文之間的關系。

　　擁有自治服務的應用程序并不表示需要將上游系統的數據庫復制到下游系統。數據庫復制將迫使本地系統承擔過多的職責，它需要創建一個共享內核，而這并不是真正意義上的自治。

　　處理不可用的一個 好辦法是將其顯現出來。

　　使用資源可用性狀態的好處并不只是技術上的，還有商業上的。

　　需要記住的是，對于一個非常詳細的上下文映射圖，我們很有可能無法對其進行實時更新。

文章轉載自：Ruby_Lu

原文鏈接：https://www.cnblogs.com/afei-24/p/17848031.html