一個典型的上下文映射圖
映射圖可以反映 哪些地方需要與其他團隊進行交流。
上下文映射展示團隊之間邊界。促進不同團隊之間的交流。
跨團隊協作避免出現： 客戶方、供應方的關係。
如果對方團隊決定維持現狀，你的團隊陷入尊奉者，被動處理的情況，實踐中，儘量避免，你可以藉助外力，或者尋找合適的機會，把技術包袱巧妙的處理掉。
你需要識別出項目中每一個模型並確定好他的界限上下文， 每個界限命名。該名字應該是通用語言的一部分。描述模型直接的連接點，並將模型之間的翻譯轉換成顯示的勾勒出來。
上下文映射圖表現的是項目當前的狀態，若項目發生變化，你可以到那時纔對上下文映射圖做出相應的更新。
上下文映射圖並不複雜，也不需要那麼正式
上下文映射圖，並不是一種企業架構，也不是系統拓撲圖，
上下文更多的展示一種組織動態能力 organizational dynamic
可以幫助我們識別出有礙項目進展的一些管理問題，上下文映射圖更多的是 項目管理者繪製，維護。
統一的命名規則，最好有產品牽頭負責。
上下文映射圖，需要展現在顯眼的位置，wiki 的首頁。
上下文的關係
合作關係 partnership
兩個上下文要麼一起成功，要麼一起失敗，建立了一種合作關係，需要一起協調開發計劃。P80
共享內核 Shared Kernel
對模型和代碼的共享將產生一種緊密的依賴性，對於設計來說，這種依賴性可好可壞。我們需要爲共享的部分模型指定一個顯示的邊界，兵保持共享內核的最小化。共享內核具有特殊的狀態，在沒與另一個團隊協商的情況下，這種狀態是不能改變的，我們應該引入持續化集成的過程來保證共享內核與通用語言等一致性。
典型的例子是 一個客戶管理系統和一個商城共享一個 企業資料模型，這時候儘可能的控制共享的模型。
客戶方-供應方開發（Customer-Supplier Development）
兩個團隊處於上下游關係，上游團隊獨立於下游團隊完成開發，此時下游的團隊開發會受到影響。
實踐中，對於上下游的開發，儘量避免作爲下游的團隊，除非你的上游團隊和你有良好的合作關係。
尊奉者 Conformist
上下游關係兩個團隊中，上游團隊已經無意願，無動力爲下游提供接口，這時候下游只能按照上游既有接口或者思路對接，
這種關係需要極力避免，或者明確各自的權責。
防腐層 Anticorruption Layer
對於上下游關係，下游需要根據自己的領域模型創建一個單獨的層，避免自己的其他系統做大的修改，一般適用於外部系統對接的時候。
例如，銀行的資產系統風控系統需要對接外部供應商的信用查詢接口，供應商很多，接口各異，你需要單獨設置一個對階層，處理外部系統的變化，將外部系統的數據模型轉換成內部統一的數據模型
開放主機服務 open host service ：
定義一種協議，讓你的子系統通過該協議訪問你的服務。你需要將該協議公開，這樣任何與你集成的人都可以使用該協議。
個人理解：這種協議算是一個約定的接口，技術角度不會自定義一種遠程訪問協議。
發佈語言 Published Language
和開放主機服務一起，例如json 或者xml 或者自定義文檔返回格式（個人理解，歡迎交流）
另謀他路
大泥球
在使用遠程調用時，注意遠程服務返回的對象和本地對象的轉換，
在實踐中，趕工期的時候會導致對象的過度重用，限制代碼的靈活性。
小結：上下文映射如圖 主要解決團隊交流協作問題
適合業務複雜的分佈式項目設計時運用。