Ch16: 獨立性
好的架構必須支援
- 系統的使用案例和運行
- 系統的維護
- 系統的開發
- 系統的部署
使用案例
系統的架構必須支援系統的意圖（想達成什麼目標）
運行
架構在支援系統運行方面扮演更重要且基本的角色
開發
架構在支援開發環境方面扮演重大的角色
- 康威定律(Conway's Law)
設計系統的架構受制於產生這些設計的組織的溝通結構。
- 反向康威定律
組織要根據他們想得到的軟件架構來設計團隊結構，而不是期望團隊盲從一個被設計好的團隊結構。
部署
架構在決定系統部署的方便性方面也扮演重大的角色
讓選項保持開放
延續 ch15-保持選項開放
架構在必須改變的各方面，都可將選項開放，使系統更易於改變
解耦各層
- 架構師可以採取 SRP 和 CCP 來分離那些因不同原因而變化的事物
- 將系統分割為解耦的多個獨立水平層，以便可以獨立修改
解耦使用案例
使用案例是劃分系統的一種非常自然的方式
- 使用案例用來切割水平層
獨立開發
系統層次與使用案例被解耦了，各分層就可以獨立開發
獨立部署
各分層可被開發為獨立的微服務來獨立部署
重複
對重複(Duplication)的恐懼
如果兩個明顯重複的程式碼沿著不同路徑發展-如果它們以不同的速率並由於不同的原因改變，那麼它們就不是真的重複
解耦模式
- 原始碼層級：控制原始碼模組間的依賴關係
- 部署層級：控制部署單元之間的依賴關係
- 服務層級：將依賴關係降低到資料結構的層次，使每個執行單元完全獨立來進行更改（例如服務或微服務）
discussion
哪種模式是最好的？
在專案早期很難知道哪種模式對於專案是最好的。隨著專案的成熟度，最好的模式可能會發生改變。
tip
將解耦盡量推至可形成服務的程度
一個好架構可以保護大部分的原始碼不會隨著情況的變化受到影響。將解耦模式看作是『選項』而保持開放，以便大型部署可以使用一種模式，而小型部署可以使用另一種模式。
總結
一個系統的解耦模式，是可能隨時間而改變的事情之一，好的架構師會預見並適當地促進這些變化發生