一個專案的上下文對映圖可以用方式來表示。比較容易的一種是畫一個簡單的框圖表示兩個或多個限界上下文之間的對映關係。該框圖表示了不同的限界上下文在解決方案空間中是如何透過整合相互關聯的。另一種更詳細的方式是透過限界上下文整合的原始碼實現來表示。
上下文對映圖為什麼重要
上下文對映圖主要幫助我們從解決方案空的角度看待問題。
假定你期望大泥球維護團隊提供一套新的API。然而，他們卻並不打算這麼做，或者他們根本就不知道你的想法。此時你的團隊和大泥球維護團隊的關係變成了 客戶方-供應方 的關係。由於大泥球團隊決定維持現狀，你的團隊不得不陷入一種遵奉著關係中。這樣的關係可能導致你的專案延期交付或者徹底失敗。
儘早繪製上下文對映圖，這樣可以迫使你仔細思考你的專案和你所依賴專案之間的關係。
繪製上下文對映圖
上下文對映圖表現的是專案當前的狀態，如果專案會在將來發生改變，你可以到那時才對上下文對映圖做出相應的更新。關注於當前的專案狀態可以幫助你瞭解你正處的位置，並幫助你決定如何走出下一步。
繪製一個上下文對映圖並不複雜。通常，首選在白板上手繪對映圖，此時你可以採用 [Brandolini] 的風格。如果你打算使用一個繪圖工具來繪製上下文對映圖，請注意不要把圖畫得太正式了。
上圖3.1中，圖中限界上下文的名字和彼此之間的整合關係只是佔位符而已，在真實的上下文對映圖中，我們將代之以實際的名字。
有時，我們希望對上下文對映圖的某些特定部分進行放大，以向裡面加入更多的細節，這只是從另外一個角度來看待同一個限界上下文。除了邊界、關係和翻譯，我們可以可能希望加入其他的一些內容，比如模組、聚合，或者團隊的分佈資訊等。
所繪製的所有對映圖，包括文字，都可以裝訂在同一份參考文件中，只要這對團隊是有價值的。在這個過程中，我們應該避免那些繁文縟節性的儀式，保持簡單和敏捷。向框圖中加入過多的細節對團隊並無多大幫助，交流才是關鍵，我們應該將交流對話也加入到上下文對映圖中。
上下文對映圖並不是一種企業架構，也不是系統拓撲圖。但是，它可以用於高層次的架構分析，指出諸如整合瓶頸之類的架構不足。上下文對映圖展現了一種組織動態能力，它可以幫助我們識別出有礙專案進展的一些管理問題。
並不是說限界上下文邊界一定得密不透風，而是：對於任何上下文邊界，開發團隊都希望協作上下文能夠完全地控制所進所出，還包括進出的原因。否則，該上下文便會出現一些不受歡迎的“拜訪者”。對於模型而言，這些“拜訪者”通常會導致混淆和BUG。建模人員應該是友好的，但是友好的前提是秩序與和諧。任何進入邊界的外部概念都應該持有充分的理由，甚至需要和邊界內的模型保持良好的相容性。
在理解充分的情況下，要繪製上下文對映圖並不難，但是通常來說，我們並不會將對映圖中的所有內容都顯示出來。在迭代過程中，思考和討論可以幫助我們改進上下文對映圖，比如對整合點進行改進，這將有助於描述限界上下文之間的關係。
擁有自治服務的應用程式並不表示需要將上游系統的資料庫複製到下游系統。資料庫複製將迫使本地系統承擔過多的職責，它需要建立一個共享核心，而這並不是真正意義上的自治。
處理不可用的一個 好辦法是將其顯現出來。
使用資源可用性狀態的好處並不只是技術上的，還有商業上的。
需要記住的是，對於一個非常詳細的上下文對映圖，我們很有可能無法對其進行實時更新。