用事件風暴分解單體設計微服務 - capital
作為軟件工程師和架構師，我們經常面臨為遺留系統創建目標微服務架構的挑戰。這些系統通常是已經存在多年的大型單體應用程序，通常具有很多依賴性，并且通常在您的公司中沒有一個人了解這一切。在這些情況下，一群領域專家是理解圍繞業務上下文和所需功能的“原因”的關鍵，上下文對于創建成功的架構至關重要。
通常，您首先創建一個業務能力模型或分類法來繪制業務能力并將它們在特定級別分組下對齊。模型/分類法表示應用程序所需的一組功能集合。
雖然這是有幫助的，但它有一些差距。分類法本身并沒有提供更廣泛的用例上下文，也沒有提供有關如何將功能分解為微服務的洞察力。這就是事件風暴可以提供幫助的地方。
事件風暴由Alberto Brandolini創建，事件風暴是一種交互式方式進行領域驅動設計(DDD)，它將業務和技術部門的領域專家聚集在一起。在本文中，我將提供事件風暴的深入迭代示例、使用它的一些經驗教訓，以及如何將其應用于您的架構工作。
首先想澄清一些關于事件風暴的常見誤解：
誤解 #1 — 與 DDD 相同
雖然事件風暴基于許多 DDD 概念——包括有界上下文和聚合——但正式的 DDD 往往很復雜，需要大量的培訓。事件風暴側重于讓所有領域專家參與的交互式協作白板練習。它更簡單，不需要像正式 DDD 那樣進行大量培訓。
誤解#2——它與設計思維相同
事件風暴和設計思維都利用了交互式業務流程映射練習和白板。它們的不同之處在于，事件風暴側重于定義微服務架構的分解和分類。它還關注業務流程中當前正在發生的事情，稱為事件。設計思維涉及一個分階段的過程，包括問題定義、需求發現和基準測試、構思、原型設計和測試。它還更多地關注同理心和痛點。
事件風暴過程是如何工作的
現在讓我們深入了解事件風暴的細節。首先要了解的事情之一是捕獲的有關域的不同類型的詳細信息。這些不同類型的細節通常由不同顏色的便簽表示。
讓我們詳細介紹其中的每一個。
- 事件（橙色）：這些是事件風暴中最重要和最廣泛使用的組件，代表領域事件和與領域專家相關的任何事情。它們是用過去時寫成的，并提供了用于后面分類步驟的基本細節。
- 命令（藍色）：這些是做某事的請求。它們可以源自用戶或系統，也可以源自其他事件。
- 系統（粉紅色）：這些代表域中涉及的系統。它們可以發出命令或接收命令以及觸發事件。
- 用戶（黃色）：這些是參與流程的人類用戶。他們可能是一個人，也可能是一個部門/團隊。黃色便簽有助于顯示業務流程的工作流程有多復雜，具體取決于所涉及的部門數量和來回的數量。
- 聚合（棕褐色）：這是第一級分類，可以被認為是一組事件操作的“事物”。通常，它們是一個名詞，可以在一組相互依賴的事件中識別出來。
- 讀取模型（綠色）：這表示可能對用戶或系統做出決策至關重要的數據。我沒有看到經常使用這個，但是當需要強調用戶看到的數據時它會很有幫助。
- policy政策（灰色）：這些代表可能需要執行的標準或規則，例如合規性政策的規則。
現在我們了解了我們想要在域中發現的不同類型的事物，讓我們通過一個示例來介紹事件風暴的每個迭代步驟。對于我們的示例，我們將對通用電子商務站點的域進行建模。
步驟 #1 — 事件發現
事件風暴的第一階段是事件發現階段。基本上，房間里的每個人都在寫事件并將它們貼在墻上。將此階段視為集思廣益，因此請避免在此階段應用任何分析或過濾，因為它只會減慢速度。別擔心，該過程中的后續步驟會清理干凈。
此步驟通常需要最長的時間，并且留出足夠的時間來捕獲事件的基礎非常重要。以電子商務網站為例，一些可能的事件可能是訂單提交、付款處理或庫存更新等。此階段的輸出示例如下所示：
步驟 #2 — 按順序放置事件
接下來的一系列步驟通過按順序（通常從左到右）放置事件來幫助識別任何丟失的事件。建立順序后，您可以倒退以幫助識別其他事件。在我們的電子商務示例中，首先輸入訂單信息，然后檢查庫存。在將它們按順序排列時，我們發現我們為正在執行的輸入檢查遺漏了一個事件。提示 - 當多個事件同時發生時，您可以將它們垂直堆疊，如下所示：
第 3 步 — 對更廣泛的生態系統進行建模
把事件序列后，下一步就是模擬出更廣泛的生態系統通過提問，如，圍繞事件“觸發什么事件？它是一個系統嗎？一個用戶？另一個事件？涉及哪些命令？” 這個額外的上下文對于理解域的當前狀態非常有價值。在我們的示例中，用戶觸發訂單信息輸入事件，他們通過網頁（系統）進行操作。
步驟 #4 — 簡單的事件分類
此時，所有詳細事件及其相關部分都應建模，并在您準備進入分類時。
第一種分類稱為聚合。這些是名詞或事物，事件發生作用。DDD 也有一個實體的概念，您可以將其視為聚合的下一個級別。根據我的經驗，將聚合和實體視為相同有助于簡化事情，使人們更容易理解。在我們的示例中，庫存、訂單、報價都是聚合的示例。它們是事件運行的對象。
步驟 #5 — 事件的有界上下文分類
現在我們已準備好進行分類的有界上下文級別。所有相關事件都將落入一個單一的有界上下文中。例如，所有與購物車相關的事件都屬于購物車有界上下文。這里要記住的一個重要的微服務概念是，如果它一起變化，它應該一起變化。我們希望盡可能消除有界上下文之間的依賴關系。如果語言在事件之間發生變化，則表明您已進入不同的有界上下文。
例如，從查看促銷優惠到結帳時，語言正在發生變化。這最好在白板上完成，您可以簡單地圍繞相關事件繪制輪廓并適當標記有界上下文。
第 6 步 — 將它們放在一起
現在我們已經完成了事件風暴的步驟！您現在可以使用有界上下文和聚合來了解所需的微服務。通常，有界上下文中的聚合代表一個或多個微服務。
在我們的示例中，訂單捕獲有界上下文將具有與訂單和庫存相關的微服務。您會注意到 Order 也存在于 Shopping Cart bounded context 和 Order Fulfillment bounded context 中。這沒關系，因為這表明它們是不同的微服務，因為它們處于不同的有界上下文中。他們可能都在做與訂單相關的事情，但他們做的事情是不同的。在單體應用程序中，這些將被捆綁在一起創建耦合，但在微服務架構中，我們將它們分開以實現獨立性。
附加步驟#7：創建能力
現在您擁有大量信息來幫助您啟動目標架構。根據我的經驗，我發現添加一個從事件創建功能的步驟很有幫助。通常，能力是現在時形式的事件。然后可以將能力映射到各種目標能力架構視圖中的有界上下文和聚合。這些不同的視圖為建筑師和工程師提供了一個經過深思熟慮的藍圖來構建他們的目標狀態。
用事件風暴分解單體 - capitalwww.jdon.com
