架構強弱比較：基於業務領域劃分的團隊更強 - martinfowler

好的技術設計決策嚴重依賴於上下文！定期為共同目標而合作的團隊能夠定期溝通並快速協商變更。這些團隊表現出強大的一致性，並且可以利用這種強大的力量做出技術和設計決策；而獨立工作且協作頻率較低的團隊和部門之間存在越來越弱的力量。

技術治理和所謂的“良好架構”大多采用“一刀切”的方法來考慮。許多組織試圖在各個級別應用相同的嚴格治理：限制技術選擇，並剝奪團隊的權力；而有一部分其他人（banq注：所謂平臺團隊）則允許團隊在所有級別上完全自治，這意味著團隊可以不受任何限制地做出自己的選擇。這兩種方法都不是理想的。

舉一個具體的例子，我們早就看到整合架構師在架構的所有級別上都在努力尋求“一個真正的”整合方法。他們引用了“最佳實踐”，強制要求極其鬆散的耦合、向後相容的介面以及對所有級別的每個系統互動進行仔細封裝。在許多情況下，這種通用方法造成了許多不必要的複雜性和延遲 - 但是您如何確定可以更快地移動並減輕這些要求的地方？

MYOB 團隊

在MYOB，我們根據現代數字產品組織的行之有效的原則來安排我們的團隊。團隊與我們的產品能力和業務能力保持一致，並負責其軟體和基礎設施的規劃、交付、維護和支援的所有方面。

團隊被分組到領域中，這些域彙集了相關的功能，在域級別工作的一些領導和支援角色。域被進一步分組為稱為“垂直Verticals”，一種更大的組織單位，垂直代表了我們客戶群的主要部分。

在本文中，我想解釋這種結構如何為我們的技術選擇和設計決策提供資訊，根據決策的範圍（或“爆炸半徑”），可能適用不同的方法。我喜歡的概念模型是組織不同部分之間的吸引力。

在一個領域內 = 強大的力量

在一個域內，我們有多個團隊，每個團隊負責域內的某些功能和底層系統。有時這是完全一致的，每個團隊都是一組整齊劃一的系統的保管人。在現實中，這通常是不完美的，因為某些系統的託管是跨團隊共享的——通常是出於遺留原因。但對於一個領域內的團隊來說，有很強的一致性。

領域結構旨在將在功能上具有凝聚力的系統結合在一起——它們密切相關，處理相同的概念，依賴於共同的領域專業知識，並且經常同時發生變化以滿足客戶需求.

單個團隊的成員通常在相同的系統中工作，因此需要非常清晰且一致的工作方式、標準、技術選擇和設計方向。這是最強大的對齊力量。

同域戰隊之間，陣營力量還是很強的。知識的共享既簡單又流暢。就係統互動（例如模式）進行協商相對來說非常容易。當需要交付跨越域中系統的功能時，通常同一個人將實現每個整合點的“雙方”。

這意味著域內系統之間的“私有”互動——API 呼叫、事件、資料檔案——可以具有更緊密的耦合，而不會產生如此嚴重的成本。通過允許一些更緊密的耦合，我們可以減少版本控制和向後相容性以及避免共享依賴項的工作量。域級別的系統之間的耦合並不總是必須不惜一切代價戰勝的邪惡怪物，實際上在這個範圍內耦合可能是一件有用的事情。

在垂直範圍內 = 減弱的力量

在中間地帶，我們有我們的垂直結構，存在有多個領域（banq：筒倉）。一個領域的人們與另一個領域的人們之間的社會距離正在拉大。這使得談判和達成一致更加緊張和緩慢，因此必然會影響我們的技術選擇和方法。

整個組織=弱力量

當我們俯瞰整個組織時 ： 垂直之間的對齊力量確實非常弱。在整個景觀中原子地進行更改非常困難 ：主要是因為每個垂直領域的工作優先順序是故意獨立的。在這個層面上的協調工作必然要慢得多且有限。這意味著我們的設計決策和方法需要相應地進行調整。

如何改進？

讓我們通過探索一些可能因範圍而異的技術決策領域來使這個模型更加具體。下面的列表並不是詳盡無遺的——只是一些值得考慮的有趣例子。

• 我們如何管理技術選擇的生命週期？

1. 領域（強力）：在一個單一的領域內，應該有一小組技術選擇達成一致。通常， 對於所需的每一類技術，這都遵循Default Trial Retire。通過技術領導的非正式治理通常非常有效
2. 垂直（弱力）：在垂直層面上，將有一組稍大的商定技術選擇，以滿足多個領域的不同需求。垂直行業能夠讓人們更接近高優先順序的工作是有益的，因此在技術上保持一致很重要。解決方案選項和建議的更正式共享使選擇有效地保持一致。
3. 整個組織（弱力）：調整和管理技術選擇的最弱力量是在整個組織層面。MYOB 技術雷達在首選技術方面設定了方向。解決方案選項和建議鼓勵對話並改善一致性。

• 共享程式碼和基礎設施

我們可以共享程式碼庫和內部庫以供重用嗎？我們可以共享基礎設施以減少重複嗎？

1. 領域（強力）：在單個域內，即使是跨 3-5 個團隊，我們也應該擁有高頻寬通訊和近距離獲得授權的領導。這意味著當需要對共享程式碼或基礎架構進行更改時，我們可以快速通知併為更改做好準備。共享程式碼和基礎設施引入的耦合影響較小。
2. 垂直（弱力）：共享程式碼、人工製品和基礎設施通常可以在垂直級別進行管理 - 但應仔細監控引入的阻力。
3. 整個組織（弱力）：整個組織級別的共享程式碼僅限於高度穩定、高度有用的東西。大多數情況下，這些東西僅限於可以分發和版本化並仔細更改的庫。共享基礎設施是類似的——在組織範圍內，共享基礎設施必須具有很高的價值，並且被很好地封裝（“即服務”，自助服務）。它應該很少需要針對單個團隊的需求進行核心更改。

• 程式碼貢獻模型

團隊是否可以將程式碼更改貢獻到其他團隊的程式碼庫中，以避免等待其他團隊完成工作？

1. 領域（強力）：在單個領域內——在實踐和技術方面高度一致——團隊跨團隊邊界貢獻程式碼是非常合理的，一種集體程式碼所有權擴充套件到整個領域。每個系統的監管仍然應該清楚地理解，通常最好保持在一個團隊內。
2. 垂直（弱力）：在垂直領域內，跨系統發生程式碼貢獻是很常見的，例如原始碼控制中的拉取請求——只需要少量的延遲和返工。
3. 整個組織（弱力）：在整個組織層面，有效管理跨垂直領域的貢獻通常非常困難（有時是有害的）。當系統本質上很複雜、在準確性、效能、隱私和合規性方面非常關鍵或敏感時，尤其如此。當建立全新的系統功能時，它可以很好地跨垂直協作，甚至一起進行結對程式設計。然而，隨著功能的建立和對其他垂直領域變化的需求增加，需要投資以確保這些系統可以安全地擴充套件和配置。這些變化本質上通常是架構性的——將“核心”和複雜的子系統分開，並引入模組化以使擴充套件更易於管理。

• 整合模式

我們將如何將系統連線在一起？

1. 領域（強力）：在單個域內擁有的系統相對容易以密切協調的方式進行更改。例如，這意味著（稍微）減少維護介面向後相容性所需的努力。甚至像資料庫級整合這樣的“禁止”方法在單個域中的系統內的影響也較小。雖然我們不應該故意以這種方式構建一個系統，但如果它存在，那麼我們可以將影響控制在單個域中。
2. 垂直（弱力）：必須在一個垂直領域內跨多個域協調的更改應該很少見，但可以在絕對必要時進行管理。 API 合同的擴充套件合同更改在影響包含在垂直範圍內的情況下非常有效。
3. 整個組織（弱力）：釋出到整個 MYOB 的 API 和介面（例如事件）必須高度關注釋出的模式、版本控制、向後相容性、契約和棄用策略。高耦合整合（例如 ETL、資料庫整合）的影響非常大，應該絕對避免。

結論

在任何規模不小的組織中，每天都會做出許多技術決策。多年來，我們一直努力使團隊能夠做出更貼近工作的決策，而無需對每一個決策進行嚴格的集中治理。實現“統一自治”並非易事，需要不斷平衡和調整。簡單的模型可以幫助團隊瞭解如何在上下文中做出正確的決策。在本文中，我描述了 MYOB 如何將我們的技術治理方法與我們的組織結構和動態保持一致。意識到我們組織內的這些一致性力量使我們能夠了解什麼是容易的，什麼是困難的，並因此做出更好的技術選擇。