一個人、一個月、5000 行程式碼——架構模式不重要。你知道每一行在哪裡，知道改了這裡會不會壞那裡，改起來很快。
十個人、兩年、100000 行程式碼——架構模式開始重要。你沒辦法記住所有的 code，你不知道那個新加入的工程師把業務邏輯塞進了哪裡，你不確定修這個 service 會不會悄悄影響另一個。
架構模式存在的原因，是解決系統超過單人可以掌控的規模之後，如何讓多人協作不失控。
沒有共識時會發生什麼
想像一個沒有明確架構的專案，十個工程師對「訂單邏輯應該放哪裡」有十種答案：
- 工程師 A 把它放在 Controller（因為這樣最快）
- 工程師 B 覺得應該在 Service（因為 Controller 要保持薄）
- 工程師 C 的判斷是 Repository（因為它需要查資料庫）
- 工程師 D 直接在 DB trigger 裡實作（因為這樣保證 atomic）
六個月後，這個系統裡的「訂單邏輯」散落在四個不同的層，沒有人清楚地知道完整的流程在哪裡。改一個業務規則，你要搜遍四個地方確認沒有其他地方在做類似的事。
這不是因為那十個工程師能力差——這是沒有共識的必然結果。
架構模式是共同語言
當團隊說「我們用 Clean Architecture」，它帶來的不只是一套 folder 結構，而是一套共同決策框架：
- 「這段 HTTP 解析邏輯放哪？」→ Interface Adapter 層，不進 domain
- 「這個業務規則需要存取資料庫嗎？」→ 透過 Repository 介面，domain 不直接碰 DB
- 「這是應該寫 unit test 還是 integration test？」→ Domain 邏輯可以 unit test，infrastructure 需要 integration test
這些問題在沒有架構模式的情況下，每次都要開會討論，每次結論都可能不一樣。架構模式把「一類決策的答案」固定下來，讓工程師把精力放在業務問題上，而不是反覆爭論 code 應該放哪裡。
架構模式不是從一開始就要選
這是關鍵——架構模式在系統複雜度達到需要它的程度之前，都是負擔，不是收益。
MVP 產品從 Layered Architecture 起步是完全正確的選擇。等到業務邏輯複雜到一個 service 有 500 行、單元測試寫不下去、換資料庫碰到太多阻力，那才是引入 Clean Architecture 或 Hexagonal 的時機。
每一種架構模式的複雜度都有代價。在問題還沒出現時引入，只是讓系統更難上手，讓新人的 onboarding 更痛苦，讓簡單的功能變複雜。
架構模式是問題的解法，不是先進的象徵。
下一篇 → 架構模式演進驅動力