事件風暴創始人Alberto：團隊拓撲和DDD上下文對映的關係

該文是事件風暴創始人Alberto最新文章，談論了DDD中有界上下文BC劃分與團隊組織劃分方式是兩種不同目標方式，不能簡單一個DDD有界上下文對應一個微服務對應一個團隊，而是在對業務知識深入理解學習過程中隨著BC或微服務動態調整團隊大小，不可能一勞永逸在專案開始之初就能確定好團隊組織結構。

正如Matthew Skelton和Manuel Pais所著的書中所描述的那樣，團隊拓撲的概念正受到全世界的關注。對團隊結構和目標的關注引起了有趣的討論，許多組織正在採用該模型作為其開發團隊組織的參考。

同時，由於問題空間似乎與上下文對映的某些高階概念重疊，因此領域驅動設計從業人員也有種似曾相識的感覺。這是我嘗試瞭解兩全其美並瞭解不同方法的利弊的嘗試。

問題空間主要是未知領域

大多陣列織有機地增長，在積壓的壓力下規模不斷擴大。規模不斷壯大的團隊將不得不分裂，能力將變得更加狹窄和專業化。然而，標準的劃分方法（即使不是很多）已經被議論不休，到底是圍繞業務能力劃分還是周圍技術技能劃分？結果是永遠不會完美，留給決策者的感覺，也許另一種方法本來可以更好...

更糟糕的是，每個組織都將調整團隊和組建團隊的責任交到不同的人手中：這是團隊領導者的責任，還是開發負責人？還是CTO？為此，我們需要特定的角色嗎？我們是否總是需要升級到生態系統級別，還是團隊之間的協作只是一個本地問題？

你被spotified了嗎？

缺乏參考模型也說明了Spotify模型的流行：一個在團隊模型和協作模型上嘗試不同模型的組織迅速成為靈感的來源，並帶來了許多意想不到的後果。像精益和豐田一樣，其他人也遵循該模型，而沒有過多地關注使該模型在特定環境下可行的要素。

簡而言之，大多數無關緊要的軟體開發組織在此領域都會遇到某種摩擦。軟體團隊之間的協作是成功公司的關鍵基本特徵之一，但是無摩擦協作似乎是一種幻想，因此，如果IT專業人員尋求指導，這並不奇怪。

團隊拓撲分類

團隊拓撲描述了四種團隊型別：

• 基於流程協調的團隊專注於特定的業務能力，理想情況下是跨職能的；
• 平臺團隊為其他團隊提供公共服務；
• 複雜的子系統團隊一支高度專業化的團隊，並且對系統的一部分有特定的瞭解；
• 支援團隊的專家團隊，指導和幫助其他團隊發展和改進。

儘管這些概念並不新鮮-它們源於對許多不同生態系統的觀察-有趣的是，它們提供了詞彙表和一些參考模型。您可能希望將此原型列表視為吸引優秀團隊的吸引者，但同時請注意，它們只是四個！

您的組織正在做的一些奇怪的事情未在此處列出，也許是有充分的理由的。這些是運作良好的團隊的參考實現。

三種互動模式

據團隊之間的關係，描述了三種模式：

• Collaboration 協調：當兩個團隊緊密合作以實現共同目標時進行協作；
• X - as a service 某個東西作為服務：在使用方面有聯絡的情況下即服務，但很少有具體的協作；
• Facilitation 便利：一個團隊正在幫助一個團隊擺脫障礙。

四種團隊型別與三種互動方式如下圖：

上下文對映模式

戰略性領域驅動設計提供了關於相同問題空間但結構不同的有趣觀點。

幾乎沒有明確提及團隊，但主要假設是在中型軟體組織中，這兩個概念之間存在緊密的對映關係，因此重點主要放在有界上下文上。

是有界上下文團隊嗎？

不，有界上下文的定義類似於給定模型的適用範圍。但是，只有當一個團隊負責模型的給定部分，並在整個社會技術體系中建立聯絡（與業務代表交談）時，才能進行復雜的領域理解，這是領域驅動設計的基本要素。並測試程式碼，與使用者互動等）。

DDD社群對此有一些公認的智慧，讓我們明確一點。

• 一個團隊對應多個有界上下文

一個團隊可以管理多個BC嗎？是的，這通常是小型組織的規範。

但是，好吧……大多數小型組織似乎對邊界分離不太在意。實際上，實現良好分離的唯一方法是顯式實施分離：從大型可見對映到程式碼庫分離。

實際上，最難管理的是相關開發人員的認知負擔。您一次只能深入瞭解一個模型。儘管一個團隊可以建立許多模型，但您必須非常善於明確界限。

•  更多的團隊對應一個有界上下文

我們可以有兩個團隊在同一個模型上工作嗎？顯然，是的。我的意思是：繪圖似乎很簡單。不幸的是，在相同界限上下文下工作的兩個團隊通常是騷亂的前奏。團隊通常有不同的積壓和優先順序，歧義會迅速在程式碼庫中腐爛，從而加速向“大泥巴”的過渡。通常，您不會擁有如此龐大的BC，足以證明有多個團隊在為他們工作。所以不行。

有趣的是，Spotify模型在該方向上有所發展，放寬了程式碼庫的所有權，以降低協調成本（再次是通訊頻寬），同時減輕了採用強大的工程實踐而降低質量的風險。但是，它們沒有BIG共享的有界上下文，而是許多具有寬鬆所有權規則的較小的上下文。

• 一個團隊對應一個有界上下文

理想的選擇似乎是在有限的範圍內規定一支團隊參與。

但是一些細節被遺漏了。例如組織規模。上次檢查時，我在內部軟體中計算了20種不同的有界上下文。這是否意味著我們需要20 *（7±2）個開發人員來編寫我們的軟體？對於一家5人的公司？Come on！

但是規模並不是這裡唯一的問題：不同的BC並非以相同的速度發展，相同的將會增長。另一個會穩定下來，理想情況下會長時間保持不變，但是閒置團隊的概念在企業中並不那麼流行，一個風險是因為團隊填滿了積壓的訂單。團隊與有界上下文之間的關聯是暫時的，並且會隨著時間而變化。

協作模式

上下文對映的重點不是團隊的外形大小形狀，而是必須支援協作的模型之間的關係。

一個有趣的概念是上游（上文）還是下游（下文）的概念：將一種模式與另一種模式的政治影響相對應。但是基於這種型別的推理，我們有一些描述可能的協作型別的模式。下面是針對DDD上下文對映的一個簡短摘要。

• 夥伴關係模式：兩個團隊相互依賴，併為實現共同的目標而合作。
• Customer-Supplier客戶-供應商模式：依賴性不太對稱，優先順序可能會有所不同。無論如何，團隊之間還是可能需要溝通的。
• Conformist遵從者模式：遵從的一方更改會最少。下游方要想得到他們所得到的。
• 反腐敗層：仍有利於下游，但我們未採用外部模型。實際上，我們正在編寫一個厚介面卡模式，以使我們的模型與外部模型嚴格分開。
• Open-Host開放主機模式：利於上游，我們的模型可以在我們的條件下提供給外部使用者。當然，我們需要通過文件等明確說明這些條件。
• Published Language:釋出的語言模式：使用一種專門的交流通用語言可以使更大範圍的對話成為可能。
• 共享核心模式：一部分在不同模型之間可能是相同的，但這意味著在修改此程式碼時需要有更高的關注度和質量，這裡就別提依賴性了。
• 分離模式：最好的依賴關係就是我們所沒有的依賴關係。有時，將事情分開是這樣。
• 泥濘大球（Big Ball of Mud）：如果沒有適當的邊界，並且程式碼庫成為工作的可怕之地。

在DDD中，當繪製“上下文對映”時，這種分類變得很有趣，繪製對映會迫使我在開始專案之前詢問相關問題。例如，如果我的團隊打算在一個不可靠的平臺上，在一個業務關鍵專案上保持一致，那我會揮舞紅旗。

從早期開始，我就喜歡使用上下文對映模式來捕獲不同費用支出上不同方法的成本。一個合作伙伴需要更少的程式碼，但需要很多溝通頻寬就成為可能，而一個反腐敗層正好走向相反的方向，寫更多的程式碼，因為沒有對話是可能的。遵從者Conformist將使您只需要很少的程式碼和對話就可以了，但是卻要降低質量。沒有免費的午餐！

溝通交流頻寬實際上是這裡的關鍵因素。如果沒有足夠的頻寬來支援它，那麼協作就不會發生。

比較兩種目標

最明顯的區別是上下文對映目標不是團隊，而是模型。另一方面，“團隊拓撲”的目標建議是：針對模型的認知會不斷進行優化，這與每個有界上下文中只有一個團隊的概念非常吻合。這是兩種不同的目標。

• 兩種目標針對現在或將來的兩種狀態

團隊拓撲為期望的狀態提供了參考目標，而DDD上下文對映為評估當前狀態提供了更細粒度的模式。

泥漿大球顯然不是理想的狀態，但這是描述您的可怕日常現實所需的詞典的一部分。

我這裡確實將上下文對映用於將來的狀態，但主要是作為軟體設計工具，而不是組織設計工具。在這裡，團隊拓撲似乎在用作參考模型方面具有優勢。

• 選擇有後果

兩種目標的共同點是使結果明確。協作的成本很高，因此需要適當考慮這些成本。我去過很多地方，管理層邀請團隊進行更多的溝通，同時填寫積壓和增加截止日期，從而使溝通變得幾乎不可能。

僅有三種互動型別團隊拓撲（Team Topologies）的輕量級教條主義是迫使管理層做出選擇並承擔後果的一種好方法。僅僅告訴人們合作和溝通並不是一種策略。

同時，快速更新我們的當前狀態上下文對映仍然是檢測當前協作狀態中是否存在搗糨糊的好方法。

1. “我們正在與A團隊合作：我們每週都有會議！” →客戶供應商模式？
2. “他們只是對我們要求的每件事說'不'。” →不...遵從者模式。

• 斷裂平面Fracture planes

團隊拓撲將斷裂平面討論為將系統分解為不同流的自然方法。但是我對領域驅動設計非常感興趣，無法愛上這個隱喻。好吧，我知道有個理想的位置，可以將系統切入鬆散耦合的有界上下文，並有效地劃分團隊之間的職責，我在書中寫了整整一章，內容涉及如何從Big Picture EventStorming中提取此資訊。

但是我也知道，要打破整體巨石，那絕不是要切斷堅固的板岩。這更像是在有分支和節點的地方砍木頭。您將嘗試遵循這條路線，但是您將意識到，有些事情並不會那麼容易被分開：有些東西會以錯誤的方式共享，但是使用起來又很大又很危險。

切斷的地方可以是一個大類，一個大表或兩者的組合。大混亂處在一切中心。

這就是隱喻聽起來對我來說太容易了的地方。有很多方法可以解決這個問題（我在一箇舊的演講中談到了它的實質），但是它們需要一定程度的精通。

還有需要考慮：

• 組織規模：當您的開發車間為20+或50+時，團隊拓撲開始變得很有趣，而當您以獨奏模式進行編碼時，也會存在有界上下文。
• 業務壓力和資產組合管理：如果沒有積壓壓力的健康檢查，則設計團隊之間的完美和諧將慘遭失敗。如果團隊承受壓力，協作將不會按預期方式進行，但是我仍然看到太多組織無法為多個從屬團隊進行計劃。

最後，我保留了我最喜歡的想法：我認為，當今圍繞“團隊拓撲”進行討論的最重要的結果就是關於一個理想狀態是什麼樣的。大多陣列織從未見過健康的組織（嚴酷但真實），因此提供參考模型絕對是一件好事。

請不要陷入"將這種理想狀態就視為穩定"的陷阱，也不要一勞永逸地解決團隊結構問題。每個解決方案都將是短暫的。合作是暫時的，每當上下文發生變化時都需要進行稽核。但是，您肯定會擁有更好的工具來做出正確的決定。