使用設計畫布發現和建模有界上下文 - Nick Tune

banq發表於2019-07-23

我們如何將大型系統分解為更小，更易於管理的模組化元件？在領域驅動設計中，大型系統被分解為有界上下文，這些上下文在程式碼中成為微服務和組織中的團隊的自然邊界。
識別良好邊界沒有捷徑可走。對業務和領域的廣泛而深入的瞭解至關重要。本文介紹的方法圍繞這些需求而設計，並使用兩個工具來找到最有效的系統設計：EventStorming和Bounded Context Design Canvas。
這種方法的工作方式由以下活動組成：
  • Big Picture EventStorming（最短1小時）
  • 候選的上下文建模（最少30分鐘）
  • Domain Flow故事（最少30分鐘）
  • 有界上下文設計畫布（最少90分鐘）
  • 精煉上下文探索（最少45分鐘）

我建議為本次研討會至少分配一整天時間。這將幫助您瞭解實際需要多長時間才能正確完成。如果你只有一次機會讓所有人聚在一起，試著分配兩天。
理想情況下，與會者將是領域專家和技術專家的混合體。如果這很難實現，至少嘗試讓您的領域專家在第一個小時內參與。

建模基礎知識回顧
這個研討會需要很大的空間。如果你能得到的只是一個狹窄的會議室，你會對結果感到失望。每組四人需要至少四米的牆面空間。
請記住：

我們不斷在問題空間和解決方案空間之間切換。我們尋找資訊，建立模型，尋找更多資訊，改進模型等。
研討會的目標是制定選項併為未來培養或提供更好選擇的能力。

1. EventStorming
如果您想設計系統，您需要兩件事：對整個系統的足夠概述以及每個區域的足夠深入的細節。為此，我們從EventStorming開始。
EventStorming是一種協作建模技術，用於從端到端對大型問題域進行建模，同時還能夠根據需要深入瞭解詳細資訊。如果這是您的第一次，我建議在1-2小時內進行EventStorming。完成EventStorming後，我建議您將小組分成最多4人的小組。

2.候選的上下文發現
透過將您的域作為EventStorm進行廣泛和深入的建模，您可以開始將這些片段分組並組織成有界的上下文。可以使用各種技術來開始識別有界上下文。我首選的入門技巧是：

  • 從價值開始 - 確定對業務具有最高價值的域的核心部分。
  • 從簡單開始 - 透過將時間線分解為連續步驟來建立簡單但天真的模型。(banq注：可依據UML序列圖來合併同類項)
  • 尋找關鍵事件 - 尋找關鍵業務事件，指出業務流程不同部分之間的狀態變化。

最初花費不超過30分鐘完成此任務。鼓勵該小組建立有界上下文的初始模型作為起點。它不需要是完美的，它不可能是最終的解決方案。
輸出應該只是一個有界的上下文名稱列表，如在牆上貼後或寫在紙上。

從這裡開始迭代
您可以立即確定多種可能的方法來建模系統。現在，選擇一個可以使用並記下其他可能的模型（稍後會有用）。您可能還意識到您缺少域資訊。如果是這樣，請考慮進行另一輪EventStorming。

3. Domain Flow Storytelling領域流故事
如何測試我們上述設計的有效性？如何獲得改進上述設計的反饋？將這些有界上下文串聯起來看看是否可以協作解決整個業務用例。例如，如果領域流程很複雜，具有許多依賴關係和雙向關係，則會警告您的設計很脆弱，需要進一步分析。
您可以使用各種視覺化技術來建模流程和用例，包括UML序列圖和UML用例圖。我更喜歡使用領域故事的變體：Domain Flow Storytelling。
透過Domain Flow Storytelling，有界的上下文字身就是故事中的演員。因此，故事始於使用者嘗試實現一個個功能，然後是有界上下文之間的互動，這樣為使用者能提供最終的完整解決方案。
對戰略Domain Flow建模可以為您提供有界上下文的反饋。它顯示瞭如何協作並相互依賴來執行完整的業務用例。這將指導您探索其他設計機會。
您可以問自己的一個問題是：每個有界上下文的描述是否與它在Domain Flow中扮演的角色一致？如果不是，則可能需要重新設計命名或邊界。

從這裡迭代
當從Domain Flow識別有界上下文之間的關係時，您可能會立即發現明顯的設計缺陷或缺少功能。您可以自由返回上一個活動並更新篩選上下文或執行第二次EventStorming迭代。
在開始重新設計之前，您還可以記下您的設計反饋並從後續活動中收集更多資訊。

4.有界上下文設計畫布
設計過程的下一步是透過詳細說明關鍵設計標準來設計候選的有界上下文。在您的團隊中，選擇您認為最重要的有界上下文。將此活動限制為最多3分鐘。100％準確並不重要。
現在，繪製一個有界上下文設計畫布，並透過以下步驟填寫詳細資訊。我建議使用1張活動掛圖或類似尺寸的紙張。
完成以下步驟後，重複此過程，直到定義了所有有界上下文。嘗試在您確定的候選有界上下文數量之間平均分配時間。
1. 上下文概述定義
首先填寫有界上下文的名稱和描述。描述應描述上下文在域中的作用及其在業務中的作用，而不是實現細節。
接下來，確定戰略或策略分類。有界上下文是系統的核心部分，支援部分，通用部分還是其他什麼？如果您需要幫助選擇，請閱讀Vladik的帖子。
當您無法想出清晰的名稱或撰寫有凝聚力的精確描述或您的UL術語含糊不清時，請將其視為設計反饋。考慮現在重新設計邊界，或者做一個註釋並稍後返回（通常更好以後再返回）。

2. 業務規則的提煉和無所不在的統一語言捕獲
查詢最重要的業務規則或策略 - 嘗試選擇前3並將其新增到畫布。
這也是尋找關鍵業務詞彙或短語的好時機，將它們新增到畫布中的統一語言部分。這在整個研討會期間會不斷繼續新增單詞和短語，這只是一個起點。

3. 強調有界上下文提供的功能是下一個優先事項。這不僅澄清了有界上下文的作用，還提供了豐富的設計反饋。您可以開始提出以下問題：

  • 這種上下文有太多職責責任嗎？
  • 這些能力是否具有凝聚力？
  • 這些功能是否在邏輯上與名稱和描述保持一致？
  • 如果我們將此功能移到上下文之外會怎麼樣？

透過設想公共介面開始識別功能。客戶可以詢問這個有界的上下文以及它們可以呼叫哪些命令？在此處使用您的領域流的故事，以瞭解客戶在此上下文中需要的是什麼。
並非所有功能都是外部啟用的命令和查詢。一些功能可以在內部觸發，例如計劃任務，所以也要考慮這些。
有時您會注意到功能叢集，如命令，查詢和通知。如果是這樣，請在畫布上將它們聚集在一起，併為群集命名。
從這裡迭代
如果您正在努力識別許多功能，或者您覺得有些功能缺失，我建議您返回到您的EventStorm並更詳細地模擬這個有界的上下文，並具有特定的外部焦點，以尋找其他上下文/服務所需的功能。

3.1 能力分層
將畫布上的每個功能分解為子功能。這種額外的粒度為您提供了更多的功能，增加了尋找替代模型的能力。
畫布上通常沒有空間。所以找另一張紙或牆壁空間。您可以在感覺有益的情況下深入多層。

4. 依賴性
如果我們想要模組化，依賴性是必不可少的，但依賴性會導致廣泛的業務，技術和社會問題。因此，必須辨別依賴關係，瞭解其影響，並考慮其他選擇。
因此，Bounded Context Design Canvas的最後一部分鼓勵您捕獲有界上下文的關鍵依賴關係。
檢視您的EventStorm和域流程圖，確定您的有限依賴項，並注意以下資訊：
  • 其他有界上下文或服務的名稱
  • 一個簡短的句子解釋為什麼存在依賴性
  • 依賴所在的位置：此係統內部或外部系統（例如第三方服務）
  • 關係的型別：它是一個傳入的依賴（另一個服務依賴於這個有界的上下文），傳出（這個有界的上下文取決於另一個），雙向或UI（依賴是某種型別的使用者介面）

正如您所做的那樣，挑戰每個依賴項。依賴是否必要？依賴的成本和收益是什麼？如果您認為可以避免依賴，請使用小的黃色標記來標記它。
下圖是將上面幾點匯成一張圖表畫布：

使用設計畫布發現和建模有界上下文 - Nick Tune

點選標題進入原文，每個步驟對應圖中填寫部位。

5. 設計批判
現在你已經完成了畫布，花幾分鐘在你的團隊批評你有限的上下文的設計。將您的反饋組織成以下類別：

  • 好：你喜歡的設計方面
  • 壞：你不喜歡的設計方面
  • 不確定：您不確定的設計方面

6. 反思和迭代
好的設計是迭代的。在進入下一個有界背景之前，請退一步看一下大圖。你學到了什麼挑戰你的設計嗎？如果有，請立即重新構建您提出的邊界，然後繼續設計下一個有界上下文。
此時，請問自己是否已對域進行了足夠詳細的建模。你是否在努力完成畫布的各個部分？如果是這樣，請考慮在整個域中或在域的某些部分中進行另一輪EventStorming。

5.精煉探索
在為每個有界上下文建立畫布並收集設計反饋列表之後，研討會的下一部分是迴歸探索。這一次，您擁有高度精煉的知識體系，可幫助您探索更好的設計選擇。
此活動的輸出是基本上下文對映的集合- 有界上下文之間的結構關係的視覺化，以及您認為必要的任何其他圖表，如域流故事。每個團隊應至少生成三個上下文對映，每個對映都顯示系統的替代可能設計。

使用設計畫布發現和建模有界上下文 - Nick Tune

  • 最後的活動是相當自由的。目標是審查收集的所有資訊並將其用於產生多種設計。作為一個起點，我建議：
  • 檢視為每個上下文收集的所有反饋，並嘗試“糟糕”和“不確定”的反饋
  • 詢問“假設”問題......
  • “如果我們將這種能力轉移到另一個有界上下文下怎麼辦？”
  • “如果我們打破這種能力並將其中一個子能力轉移到另一個有界上下文中會怎樣？”
  • “如果我們將有界上下文分成多個上下文怎麼辦？”
  • “如果我們從這三種上下文中的每種上下文中獲取一種能力並將其用於新的上下文下會怎樣？”
  • “如果我們複製功能來破壞依賴性怎麼辦？”
  • “如果我們建立共享服務以減少跨多個上下文的重複，該怎麼辦？”
  • “如果我們孤立真正的核心能力並將其他能力轉移到一個單獨的環境中會怎樣？”

5.結束演講
為了結束研討會，每個小組應提供他們建立的上下文對映選擇，並討論每個設計的權衡。他們應該解釋他們的首選選擇和原因。
介於5到10分鐘之間通常就足夠了。
簡報中要考慮的事項：

  • 關注核心領域：每個設計如何更有效地開發系統的核心部分？
  • 比較領域流故事：一個系統設計如何降低複雜性和依賴性數量。
  • 解釋接下來要做什麼來驗證您的首選


 

相關文章