SummerSoC 2020：基於領域驅動的服務設計(SOA/微服務) – Stefan Kapferer

• 戰略領域驅動設計（DDD）的服務分解
• 上下文對映器 DSL（CML）作為DDD上下文對映的機器可讀方法
• 分解標準：如何分解一個領域並識別“邊界上下文”？
• 體系結構重構（AR）作為CML的模型轉換
• 逐步分解域的增量方法
• 從DDD模型中生成服務合同（使用MDSL語言）

戰略性領域驅動的設計和上下文對映器
隨著最近的微服務趨勢，如何將軟體系統分解為模組和/或服務的問題引起了廣泛的關注。但是，這個問題並不新鮮。帕納斯（Parnas）早在1972年就寫過一篇論文“ 關於將系統分解為模組的標準”。
如今，一個流行的答案是戰略領域驅動設計（DDD）。它強調在領域模型中需要一種獨特的詞彙（即普遍存在的語言），並建議將領域分解為所謂的“有界上下文”。一個域通常由多個子域組成。
在下面演示示例中：保險領域由幾個子域組成：客戶，保單，風險等。

當實現SOA模組化或微服務時，您將面臨一個問題，即系統應有多少個（微）服務或模組。
DDD建議識別有界上下文，併為每個上下文實現一個子系統（服務或模組）。有界上下文建立了一個邊界，領域模型只在該邊界內有效。
有界上下文中的概念和領域物件應清晰明確地定義（根據無所不在得統一語言）。如下例所示，繫結上下文可以實現一個或多個子域的一部分：

當我們將領域分解為多個有界上下文時，這些上下文如何相互整合的問題自然而然地引起了。
這就是DDD上下文對映和上下文對映起作用的地方。上下文對映說明了繫結上下文之間的關係以及它們之間的資料如何流動。以下上下文圖顯示了我們虛擬保險場景的一個示例：

圖中“ U”和“ D”表示“上游”和“下游”。«Upstream-Downstream»關係中的資料始終從上游流向下游。
這意味著：上游向下遊公開其一部分域模型（例如，透過公共API）。下游上下文可以符合上游模型（CONFORMIST），也可以實施反腐敗層（ACL）以保護自己的模型不受上游更改的影響。
上游模式是開放主機服務（OHS）和釋出語言（PL）。
如果上游上下文實現了一個公共和開放的API（banq注：RESTful等的API），該API應該由多個下游上下文以統一的方式使用，則將應用OHS模式。
已釋出的語言（PL）是域模型的一部分（banq注：JSON或XML格式或二進位制）。此模式經常與OHS結合使用。
如果某個關係上標有“客戶/供應商”，則這兩個團隊緊密合作，這意味著上游團隊會根據下游（客戶）的要求來優先處理其工作。
在對稱關係（夥伴關係和共享核心）中，存在相互依賴關係，與上下游關係相比，它們導致更強的耦合。
...
 

服務分解
將軟體系統或域分解為上下文對映（多個有界上下文）是一個迭代和進化的過程。透過提供基於不同分解標準的多個AR，可以使用Context Mapper“逐步”分解域。下圖說明了這種想法：

從領域分析開始，並首先將其域建模為一個單獨的上下文。透過在戰略DDD級別上應用AR（請參見上圖），使用者可以“逐步”分解域並迭代地開發上下文對映。我們還在戰略DDD級別上提供了重構，該重構允許分解和合並Bounded Context中的聚合。
原型化上下文地圖後，整合子系統（繫結上下文）的API便成為重要的設計問題。如何設計/實現它們，以及域模型的哪些部分暴露於其他有界上下文？上下文對映器使您可以從CML上下文對映中生成MDSL合同。透過使用MDSL工具，您甚至可以生成特定於技術的合同和程式碼，以在以後快速建立應用程式原型。
 

總結
我們的目標是透過提供易於使用的戰略性DDD的有用工具，從而來支援領域/服務建模人員、軟體架構師和軟體工程師。取代人類的工作不是我們的目標！這些工具有望為您提供支援，但是您仍然需要了解您的領域的人員以及建模者和架構師的經驗來設計好的領域模型和API。

詳細點選標題見原文。