架構特性的範圍#

傳統上，架構特性被視為系統級別的屬性——例如討論 scalability 時，通常指整個系統的可擴展性。然而隨著 microservices 等現代架構風格的興起，架構特性的範圍已大幅縮小。本章引入 architecture quantum 概念，重新定義架構特性的適用範圍。

Coupling 與 Connascence#

傳統耦合度量的局限#

傳統的 code-level coupling 指標（如 afferent 和 efferent coupling）過於細粒度，不適合架構層級的分析。

Connascence（共生性）#

1996 年 Meilir Page-Jones 提出了 connascence 的概念：

若兩個元件中的一個發生變更，另一個也必須修改以維持系統整體正確性，則稱這兩個元件具有 connascence。

Connascence 分為兩大類：

• Static connascence（靜態共生性）：可透過靜態程式碼分析發現
  • 例如：兩個 microservices 共享同一個 class 定義（如 address），改變該 class 需要兩邊同步修改
• Dynamic connascence（動態共生性）：涉及執行時期行為
  • Synchronous（同步）：呼叫方等待被呼叫方的回應
  • Asynchronous（非同步）：fire-and-forget 語義，允許服務在運營特性上有所不同

同步呼叫在分散式服務之間建立了動態共生性——在等待期間，雙方的運營架構特性必須一致。非同步通訊則能解耦這種約束，提供更大的架構彈性。

Architectural Quanta 與 Granularity#

元件層級的耦合不是唯一將軟體綁定在一起的因素。許多業務概念會語義上將系統的部分綁定在一起，形成 functional cohesion（功能內聚）。

Architecture Quantum 的定義#

Architecture quantum：一個具有高功能內聚（high functional cohesion）和同步共生性（synchronous connascence）的獨立可部署產出物（independently deployable artifact）。

此定義包含三個關鍵部分：

Independently deployable（獨立可部署）：

• Architecture quantum 包含運作所需的所有元件，可獨立於架構的其他部分運行
• 若應用程式使用資料庫，該資料庫即為 quantum 的一部分
• 傳統單體應用（使用單一資料庫）天然形成一個 quantum
• Microservices 中每個服務包含自己的資料庫，形成多個 quanta

High functional cohesion（高功能內聚）：

• Cohesion 指元件內程式碼在目的上的統一程度
• 高功能內聚意味著 architecture quantum 執行有意義的業務功能
• 在 microservices 中，開發者通常將每個服務設計為對應單一 workflow（即 DDD 的 bounded context）

Synchronous connascence（同步共生性）：

• 指 quantum 內或組成 quantum 的分散式服務之間的同步呼叫
• 若一個 microservice 同步呼叫另一個，雙方在呼叫期間的運營特性必須一致
• 例如：caller 的 scalability 遠高於 callee 時，會產生 timeout 和 reliability 問題

Domain-Driven Design 的 Bounded Context#

Eric Evans 的 Domain-Driven Design (DDD) 定義了 bounded context 概念：

• 與 domain 相關的一切在內部可見，但對其他 bounded context 不透明
• 避免跨組織共享通用實體（如統一的 Customer class），減少耦合和協調複雜度
• 每個問題領域可建立自己的實體，在整合點協調差異

Architecture quantum 概念為架構特性提供了新的範圍。在現代系統中，架構師應在 quantum 層級而非系統層級定義架構特性。

案例研究：Going, Going, Gone#

以線上拍賣公司為例，分析 architecture quantum 如何影響架構決策：

需求分析#

• 全國規模拍賣，每場拍賣可達數百至數千名參與者
• 拍賣需盡可能即時
• 競標者以信用卡註冊，得標後自動扣款
• 參與者須透過信譽指數追蹤
• 競標者可觀看即時影像串流和所有出價
• 線上與現場出價須按時序接收

架構特性識別#

分析各項需求可得出以下架構特性：

• Scalability 與 Elasticity：支援大量使用者和拍賣的突發性流量
• Performance：即時拍賣的本質要求
• Security：信用卡處理 + 過去的詐騙訴訟
• Reliability 與 Availability：拍賣師端尤其重要，連線中斷將是災難性的

識別出的 Quanta#

透過 architecture quantum 分析，可識別出不同部分需要不同的架構特性：

Bidder Feedback（競標者回饋）：

• 包含出價串流和影像串流
• Availability、Scalability、Performance

Auctioneer（拍賣師）：

• 現場拍賣師
• Availability、Reliability、Scalability、Elasticity、Performance、Security

Bidder（競標者）：

• 線上競標者和出價
• Reliability、Availability、Scalability、Elasticity

不同 quanta 有不同的架構特性需求——這直接挑戰了「架構特性是系統級別」的傳統假設，並引導架構師走向 hybrid architecture 的設計方向。