辨識軟體架構中的耦合#
架構師面臨的最困難任務之一，就是在分散式架構中理清各種交織的力量與權衡取捨。泛泛地建議「解耦」並不夠——架構師需要具體的術語和分析框架，才能在複雜系統中做出最佳決策。
Coupling（耦合）的定義：軟體系統的兩個部分是耦合的，如果對其中一個部分的變更可能導致另一個部分也需要變更。
Figure 2.1: A braid entangles hair, making the individual strands hard to identify
本書建議的現代架構 trade-off 分析步驟：
- 找出哪些部分糾纏在一起
- 分析它們如何彼此耦合
- 評估 trade-offs——判斷變更對相互依賴系統的影響
Architecture Quantum | Quanta#
Architecture quantum 是本書的核心概念之一，源自拉丁文 quantus（意為「多大」或「多少」）。
定義#
- Architecture quantum：一個具有高功能內聚（high functional cohesion）、高靜態耦合（high static coupling）和同步動態耦合（synchronous dynamic coupling）的獨立可部署產物（independently deployable artifact）
- Static coupling（靜態耦合）：描述架構中透過合約（contracts）解析的靜態依賴關係，包括作業系統、框架、程式庫等所有啟動 quantum 所需的運營依賴
- Dynamic coupling（動態耦合）：描述 quanta 在執行時期如何溝通，可能是同步或非同步的
區分靜態耦合與動態耦合的簡單方式：靜態耦合描述服務如何被「連接」（wired）在一起；動態耦合描述服務在執行時期如何「呼叫」（call）彼此。
Independently Deployable#
- 每個 architecture quantum 代表一個獨立的可部署單元
- 單體式架構（如 Layered、Modular monolith、Microkernel）必然只有一個 quantum
Figure 2.2: Monolithic architectures always have a quantum of one
- 分散式架構可能有多個 quanta，但不一定保證——若共享資料庫或中央 orchestrator，仍可能只有一個 quantum
- 獨立部署性迫使架構師必須將資料庫等共同耦合點納入 quantum 的邊界考量
High Functional Cohesion#
- 高功能內聚指的是相關元素（類別、元件、服務等）在結構上的緊密程度
- 從 domain-driven design 的角度，高功能內聚與 bounded context 的目標重疊——行為和資料共同實現一個特定的領域工作流
- 單體式架構雖從部署角度算是一個 quantum，但通常不具有高功能內聚
- 在微服務架構中，每個服務理想上模塑一個單一領域，因此展現高功能內聚
High Static Coupling#
- 高靜態耦合表示 quantum 內部的元素被緊密連接在一起，這本質上是合約（contracts）的一個面向
- 合約不僅包含 REST 或 SOAP 等格式，還包括方法簽章、操作依賴（如 IP 位址、URL）
- Architecture quantum 的靜態耦合度量涵蓋資料庫——依賴同一資料庫的系統不能算作獨立的 quanta
Figure 2.10: A shared database forms a coupling point between two systems
不同架構風格的 quantum 數量：
| 架構風格 | Quantum 數量 |
|---|---|
| Layered monolith | 1 |
| Modular monolith | 1 |
| Microkernel | 1 |
| Service-based（共享 DB） | 1 |
| Mediator 風格 Event-driven（共享 DB + orchestrator） | 1 |
| Broker 風格 Event-driven（獨立 data store） | 可能多個 |
| Microservices（各自獨立 DB） | 每個服務各自一個 |
Figure 2.3: Architecture quantum for a service-based architecture
Figure 2.4: A mediated EDA has a single architecture quantum
Figure 2.5: Even a distributed architecture such as broker-style event-driven architecture
Figure 2.6: An event-driven architecture with multiple quanta
Figure 2.7: Microservices may form their own quanta
若微服務架構的使用者介面與後端緊密耦合（透過同步呼叫），整個架構可能退化為單一 quantum。使用 micro frontend 模式可以避免此問題。
Figure 2.8: A tightly coupled user interface can reduce a microservices architecture
Figure 2.9: In a micro-frontend architecture, each service + user interface component
Dynamic Quantum Coupling#
動態耦合關注執行時期服務間的同步耦合行為，受三個交錯力量影響：
- Communication（通訊）：同步（synchronous）或非同步（asynchronous）
- 同步通訊：請求者必須等待接收者的回應（如 gRPC），呼叫端會被 block
Figure 2.11: A synchronous call waits for a result from the receiver
- 非同步通訊：呼叫者透過 message queue 傳送訊息，不需等待即可繼續工作
Figure 2.12: Asynchronous communication allows parallel processing
- Consistency（一致性）：原子性交易（atomic）或最終一致性（eventual consistency）
- 跨服務的原子性交易是分散式架構中最難解決的問題之一
- Coordination（協調）：orchestration（編排）或 choreography（編舞）
- 簡單工作流不需特別考慮協調維度，但工作流越複雜，對協調的需求越大
這三個因素形成一個三維空間，共有八種可能的組合，每種組合對應不同的耦合程度。
動態耦合的維度交叉矩陣：
| Pattern | Communication | Consistency | Coordination | Coupling |
|---|---|---|---|---|
| Epic Saga | synchronous | atomic | orchestrated | very high |
| Phone Tag Saga | synchronous | atomic | choreographed | high |
| Fairy Tale Saga | synchronous | eventual | orchestrated | high |
| Time Travel Saga | synchronous | eventual | choreographed | medium |
| Fantasy Fiction Saga | asynchronous | atomic | orchestrated | high |
| Horror Story | asynchronous | atomic | choreographed | medium |
| Parallel Saga | asynchronous | eventual | orchestrated | low |
| Anthology Saga | asynchronous | eventual | choreographed | very low |
Figure 2.13: The dimensions of dynamic quantum coupling
Sysops Squad Saga: Understanding Quanta#
在 Sysops Squad 故事中，Addison 和 Austen 透過對話理解了 architecture quantum 的實際意義：
- Architecture quantum 本質上是以架構術語定義 DDD bounded context，但額外識別出靜態與動態兩種耦合類型
- 靜態耦合可透過分析容器 manifest、POM 檔案、NPM 依賴、建置依賴清單和服務呼叫圖譜來建立
- 動態耦合關注 quanta 之間的通訊方式（同步 vs 非同步），直接影響效能、可擴展性（scalability）、彈性（elasticity）等運營架構特性
- 同步呼叫會使兩個服務在呼叫期間暫時耦合，影響效能與 responsiveness；非同步呼叫則允許兩個服務獨立運作