領域驅動設計DDD之上下文對映圖
上下文對映圖的英文是Context Map其實這個翻譯挺難理解的，上下文對映圖其實就是不同上下文是如何進行交流的關係。由於上下文對映圖內容比較少。以下內容摘自《領域驅動設計精粹》。
三種整合方式
- RPC方式
- 訊息佇列或者釋出-訂閱機制。
- RESTful方式
上下文對映的種類
-
合作關係： 合作關係存在於兩個團隊之間。每個團隊各自負責一個限界上下文。兩個團隊通過互相依賴的一整套目標聯合起來形成合作關係。一損俱損，一榮俱榮。由於相互之間的聯絡非常緊密，他們經常會對同步日程安排和相互關聯的工作。他們還必須使用持續整合對保持整合工作協調一致。
-
共享核心： 兩個或者多個團隊之間共享著一個小規模但卻通用的模型。團隊必須就要共享的模型元素達成一致。有可能他們當中只有一個團隊會維護，構建及測試共享模型的程式碼。
-
客戶-供應商： 兩個限界上下文中，一方是供應商處於上游，一方是客戶方處於下游。支配這種關係的是供應商，因為它必須提供客戶需要的東西。客戶需要與供應商共同制訂規劃來滿足各種預期，但最終卻還是由供應商來決定客戶獲得的是什麼以及何時獲得。
-
跟隨者： 上游團隊沒有任何動機去滿足下游團隊的具體需求。由於各種原因，下游團隊也無法投入資源去翻譯上游模型的通用語言來適應自己的特定需求，因此只能順應上游的模型。例如當一個團隊需要與一個非常龐大複雜的模型整合，而且這個模型已經非常成熟時，團隊往往會成為它的跟隨者。
-
防腐層： 這是最具防禦性的上下文對映關係，下游團隊在其通用語言（模型）和位於它上游的通用語言（模型）之間建立了一個翻譯層。防腐層隔離了下游模型與上游模型，並完成了兩者之間的翻譯。所以，這也是一種整合方式。
-
開放主機服務： 開放主機服務會定義一套協議或者介面，讓限界上下文可以被當做一組服務訪問。該協議是開放的，所有需要與限界上下文進行整合的客戶端都可以相對輕鬆地使用它。通過應用程式程式設計介面提供的服務都有詳細的檔案，用起來也很舒服。
個人認為比較好的方式是共享核心、防腐層、開放主機等形式的上下文對映。