康威定律

我在軟體架構領域中所推崇的從業人員，幾乎都對該領域的任何一般性定律深感懷疑。良好的軟體架構具有高度的特定性，分析在各種環境中以不同方式解決的權衡取捨。但如果有一件事他們都同意，那就是康威定律的重要性與力量。它足夠重要，影響了我所接觸的每個系統，而且它足夠強大，如果你試圖與它對抗，你註定會失敗。

這條定律可能由其作者以最佳方式陳述為：[1]

任何設計系統（廣義定義）的組織都會產生一個設計，其結構是組織溝通結構的副本。

-- Melvin Conway

康威定律基本上是觀察到軟體系統的架構與建構它的開發團隊組織非常相似。它最初被描述為，如果一個團隊編寫一個編譯器，它將是一個單次編譯器，但如果團隊分成兩個，那麼它將是一個兩次編譯器。儘管我們通常在軟體方面討論它，但這個觀察廣泛適用於一般的系統。[2]

正如我的同事 Chris Ford 對我所說：「康威了解到軟體耦合是由人類溝通啟用和鼓勵的。」如果我可以輕鬆地與某段程式碼的作者交談，那麼我就可以更容易地對該程式碼建立豐富的理解。這使得我的程式碼更容易與該程式碼互動，從而與該程式碼耦合。不僅在明確的函式呼叫方面，而且在隱含的共用假設和思考問題領域的方式方面也是如此。

我們常常看到不注意這條定律如何扭曲系統架構。如果架構設計與開發組織的結構不一致，那麼軟體結構中就會出現緊張。原本設計為直接的模組互動變得複雜，因為負責這些模組的團隊無法很好地協同工作。有益的設計替代方案甚至不被考慮，因為必要的開發小組沒有互相交談。

十幾或二十幾個人可以進行深入且非正式的溝通，因此康威定律指出他們會建立一個整體。這很好 - 因此康威定律不會影響我們對較小團隊的思考。康威定律應該影響決策制定，是在人類需要組織的時候。

處理康威定律的第一步是知道不要與之對抗。我仍然記得一位敏銳的技術領導者，他剛剛成為一個大型新專案的架構師，該專案由遍布世界各地的六個團隊組成。“我做出了我的第一個架構決策”，他告訴我。“將會有六個主要子系統。我不知道它們將是什麼，但將會有六個。”

此範例認知到位置對人類溝通的重大影響。將團隊放在同一棟建築的不同樓層就足以顯著減少溝通。將團隊放在不同的城市和時區，進一步妨礙了定期對話。架構師認知到這一點，並意識到他需要從一開始就在他的技術設計中考慮到這一點。在不同時區開發的元件需要有明確且有限的互動，因為它們的建立者無法輕鬆交談。[3]

康威定律常見的不匹配之處在於ActivityOriented團隊組織與功能開發背道而馳。按軟體層組織的團隊（例如前端、後端和資料庫）會導致主要的PresentationDomainDataLayering結構，這是有問題的，因為每個功能都需要各層之間的密切合作。同樣地，沿著生命週期活動（分析、設計、編碼、測試）劃分人員意味著需要大量交接才能將功能從構想轉變為生產。

接受康威定律優於忽略它，在過去十年中，我們看到了回應此定律的第三種方法。在這裡，我們故意改變開發團隊的組織結構以鼓勵所需的軟體架構，這種方法稱為逆康威策略 [4]。這種方法通常在微服務領域中被討論，其中倡導者建議建立小型、長期的BusinessCapabilityCentric團隊，其中包含提供客戶價值所需的所有技能。透過這種方式組織自主團隊，我們採用康威定律來鼓勵類似的自主服務，這些服務可以獨立於彼此進行增強和部署。的確，這就是我將微服務描述為主要用於建構開發組織的工具的原因。

雖然逆康威操作是一個有用的工具，但它並非萬能。如果你有一個具有僵化架構的現有系統，並且你想要改變它，那麼改變開發組織並不會立即修復。相反，它更有可能導致開發人員和代碼之間的不匹配，從而增加進一步增強的摩擦。對於這樣的現有系統，康威定律的重點是，我們需要在改變組織和代碼庫的同時考慮它的存在。而且，我建議採取小步驟，同時密切注意回饋。

領域驅動設計在康威定律中扮演著角色，以幫助定義組織結構，因為 DDD 的一個關鍵部分是識別限界上下文。限界上下文的關鍵特徵是它有自己的通用語言，由在該上下文中工作的人員組定義和理解。這樣的上下文形成了一種圍繞主題對人員進行分組的方法，然後可以與價值流保持一致。

關於康威定律需要記住的關鍵是，系統的模組化分解和開發組織的分解必須同時進行。這不僅僅是在開始時，架構的演變和人類組織的重組必須在整個企業生命週期中齊頭並進。