康威定律作為設計工具

🎯 什麼情境該想到我

當你「改一條業務規則，卻要協調好幾個團隊一起排程」的時候。

⚙️ 怎麼用（步驟 / 公式）

意圖：把「組織的溝通結構會複製到架構上」這條定律當成設計工具——先設計團隊邊界，讓想要的架構自然長出來；而不是等它反噬。

完整診斷示範：Etsy 的 Sprouter（L3503–3567）

• 病灶：Sprouter（“stored procedure router” 的簡稱，2007 年開發）坐在前端 PHP 應用與 Postgres 資料庫之間，集中資料庫存取、對應用層隱藏資料庫實作。設計初衷是「讓 Dev 團隊寫 PHP、DBA 在 Postgres 裡寫 SQL，由 Sprouter 幫他們在中間會合」。
• 對應到定律：Etsy 當時有兩個團隊（開發者與 DBA），各自負責服務的兩層（應用邏輯層與 stored procedure 層）——兩個團隊做兩層，正如康威定律所預測。
• 惡化路徑：
  • 幾乎任何新站台功能都需要 DBA 寫一支新的 stored procedure，開發者每次要加功能都得穿過一堆官僚流程 → 工作坐在佇列裡、開會、lead time 拉長。
  • stored procedure 也和 Sprouter 緊耦合，改一支就得同時改 Sprouter，讓 Sprouter 變成越來越大的單點失效；同步需求高到幾乎每次部署都造成小型中斷。
  • 關鍵量化：業務規則一變，原本只要改兩層，現在要改三層（應用、stored procedure、Sprouter），而且要跨三個團隊協調與排優先序。
• 解法：把所有業務邏輯從資料庫層搬回應用層，由一個小團隊寫 PHP ORM 層，讓前端開發者直接呼叫資料庫——把「改業務邏輯所需的團隊數從 3 個降到 1 個」。
• 節奏：新區域先用 ORM，舊站台一小塊一小塊遷移，整站移轉花了兩年，期間 Sprouter 一直留在生產環境沒下線。
• 成果：消除多團隊協調、減少交接、部署速度與成功率大幅提升、站台穩定度改善；小團隊能獨立開發部署，開發者生產力上升。

三種組織原型（Roberto Fernandez 的定義，L3579–3605）

• Functional（功能導向）：為專業、分工、降低成本最佳化。集中專業知識、有助職涯與技能發展，常有高聳的階層。這是 Operations 長期以來的主流組法（server admin、network admin、DBA 各自成群）。
• Matrix（矩陣）：試圖兼顧功能與市場導向。實務上常變成複雜的組織結構——個別貢獻者要向兩位以上主管報告——結果兩邊的目標都沒達成。
• Market（市場導向）：為快速回應客戶需求最佳化。傾向扁平、由多個跨職能專業組成，常帶來跨組織的冗餘。這是許多 DevOps 標竿組織的做法；極端例子如 Amazon 或 Netflix，每個服務團隊同時負責功能交付與服務支援。

設計原則與兩種要避免的切分（L3856–3879）

• 理想上，軟體架構應該讓小團隊能獨立產出，彼此充分解耦，不需要過度或不必要的溝通與協調。
• 要避免的兩種切法：
  1. 依職能切——例如把開發者與測試者放在不同地點，或把測試整包外包出去。
  2. 依架構層切——例如 application 一隊、database 一隊。
• 這兩種配置都要求大量跨團隊溝通協調，卻仍造成大量返工、對規格的爭議、糟糕的交接，以及有人坐著等別人。
• 同樣會侵蝕協作的還有：人與團隊分處不同樓層／建築／時區，以及主要溝通機制是工單與變更申請、或被契約邊界（外包）隔開。（L3858–3865）

原文：「These include splitting teams by function (e.g., by putting developers and testers in different locations or by outsourcing testers entirely) or by architectural layer (e.g., application, database).」（L3869–3871）

原文：「when business rules changed, instead of changing only two layers, they now needed to make changes to three layers」（L3537–3538）

🧪 我實際套用的紀錄

• （待填）

⚠️ 注意 / 什麼時候不適用

• 康威定律不是可選項，只有「順著用」和「被它反噬」兩種結果。做得差時，團隊會被緊耦合在一起、互相等待，連小改動都可能造成全域的災難性後果。（L3490–3495）
• 修 Conway 帶來的問題是長工程：Etsy 花了兩年，而且被詬病的元件全程留在生產環境。不要規劃成一次性切換。
• 中介層本身不是罪——Sprouter 的初衷是讓兩個團隊都輕鬆一點。問題出在它把「一次變更要動的層數與團隊數」變多了。判斷一個中介層好壞，就看它讓變更需要協調的團隊數變多還是變少。
• 市場導向會帶來跨組織冗餘，這是為速度付的代價；功能導向的存在理由是成本與專業深度，不是一無是處。要選的是「現在要為什麼最佳化」。（L3585–3605）

🔗 相關工具

• 工具-康威定律（《微服務設計》版本，講定律本身與「逆康威操作」的通則；本條是完整的診斷案例與可避免的切分清單）
• 兩個披薩團隊（康威定律推導出的團隊大小上限）
• 演進式架構（把緊耦合改回鬆耦合的具體手段）
• 工具-服務邊界與演進式拆分（服務邊界怎麼畫，與團隊邊界要對齊）
• DevOps手冊