「領域驅動設計」領域驅動設計中的上下文映射

• 2019 年 11 月 27 日
• 筆記

上下文映射是一個工具，它允許您識別有界上下文之間的關係以及負責它們的團隊之間的關係。

Vaughn Vernon的IDDD書中描述了幾種集成多個有界上下文的方法:

• 夥伴關係
• 共享內核
• 客戶的供應商
• 墨守成規
• 反腐敗層
• 開放主機服務
• 發布的語言

根據程式碼的情況、團隊的性質、業務本身、是否涉及第三方軟體等，應該靈活地應用每一種方法。我將試著給出一個如何使用這些的例子。

夥伴關係

它更多地描述了團隊之間的關係，而不是實際的程式碼。這種情況通常發生在兩個團隊在兩個有界的環境中工作，並且有一致和相關的目標集的時候。每個團隊至少應該理解他們的合作夥伴的一些無處不在的語言，即對他們自己的上下文感興趣的東西。當兩個有界上下文都處於項目的早期階段時，這種方法可以很好地工作，因為在早期階段，通訊比實現其他一些技術更快、更有效。當雙方變得更加穩定時，團隊可能會因為理解彼此的通用語言而承擔太多的義務。當然，如果一個團隊要在這兩個有限的上下文中工作，那麼「夥伴關係」的成本就會低得多。

共享內核

2個或多個有界上下文可以共享一個公共模型。在設計術語中，這個共享部分的通用語言對於所有相關的團隊都是通用的。在程式碼術語中，您可能有一個共享庫或服務。這通常是一個小的程式碼庫，但是隨著相關的有界上下文的發展而難以維護，因為隨著團隊自身的有界上下文的發展，團隊將傾向於採用不同的方式。

消費者/供應者

此方法將兩個有界上下文放入上游和下游，其中上游是供應商，並且必須嘗試滿足客戶(下游)的期望。但是最終決定客戶得到什麼的是供應商。這通常在同一組織內的自治環境中工作，或者如果客戶是供應商的唯一客戶。

墨守成規

此關係描述了兩個有界上下文的關係，其中上游出於某種原因沒有興趣支援下游。相反，下游必須遵循上游所提供的內容。當將一個新特性與一個已經建立的大型現有解決方案集成時，可能會出現這種情況;或者使用一組api，而下游不是唯一的客戶。

反腐敗層(ACL)

這是較低級別上的另一個上游/下游關係，其中下游有界上下文實現了自身與上游之間的一個層。這一層負責將上游給出的對象轉換成它自己的模型。這種方法將保證下游有界上下文的完整性，並使其完全不受任何外來概念的影響。此方法通常用於將新功能集成到某些現有遺留軟體中，在這些軟體中，可以將現有遺留軟體視為黑盒邊界上下文，並為新功能創建ACL。

開放主機服務(OHS) /發布的語言(PL)

我將同時討論這兩種方法，因為它們都定義了一種關係，在這種關係中，上游提供了一組關於集成模型的良好記錄或隨時可用的資訊。這是建立在早期的墨守成規的方法之上的，在早期，下游要容易得多。上游還需要提供版本支援。通常，上游有界上下文將支援多個客戶機，並且對特別支援某個客戶機不感興趣。例如，為了符合Amazon api，下游將通過理解Amazon提供的文檔對集成有信心。

總之，理解各種上下文映射技術可以更有效地集成有界上下文。同樣重要的是，首先要考慮集成是否必要並為業務帶來好處。同時使用多種方法也是可以接受的，有時是首選的。例如，擁有RESTful API自然會提供OHS，但同時，下游也可能被鼓勵實現自己的ACL，特別是當上游服務由第三方提供時。您的團隊將是根據當前情況決定使用哪種方法的最佳人員。

原文：https://medium.com/ingeniouslysimple/context-mapping-in-domain-driven-design-9063465d2eb8

本文：https://pub.intelligentx.net/ddd-context-mapping-domain-driven-design

討論：請加入知識星球【首席架構師圈】或者飛聊小組【首席架構師智庫】