架構風格#

確定了系統的架構特性後，下一步是選擇一個**架構風格（Architecture Style）**作為整體骨架。架構風格是經過反覆驗證的「系統頂層結構模板」，每一種風格在不同架構特性上有先天的強弱。選風格的本質，就是把你優先的架構特性，對應到天生擅長那些特性的結構上。

架構風格描述的是系統「整體的形狀」（單體還是分散式、怎麼切分），架構模式（Pattern）則是局部的設計手法。本章只談風格層級的取捨。

兩大陣營#

架構風格大致分為兩個陣營，最根本的分界是部署單元的數量。

flowchart TD
    Root[架構風格] --> Mono[單體類<br/>單一部署單元]
    Root --> Dist[分散式類<br/>多個部署單元]

    Mono --> Layered[分層架構]
    Mono --> Pipeline[管道架構]
    Mono --> Microkernel[微核心架構]

    Dist --> EDA[事件驅動]
    Dist --> SBA[空間導向]
    Dist --> SOA[服務導向]
    Dist --> MS[微服務]

    style Mono fill:#e8f5e9
    style Dist fill:#e3f2fd

單體類（Monolithic）#

所有元件編譯／部署為單一單元。優點是簡單、好測、低延遲；缺點是擴展性、容錯與部署彈性受限。

分散式類（Distributed）#

系統拆成多個獨立部署單元，透過網路通訊。優點是擴展性、容錯、部署彈性；代價是分散式固有的複雜度（網路、一致性、可觀測性）。

微服務、服務拆分時機、服務間通訊等屬於分散式架構的深水區，請見微服務專章。本章只把微服務當作「一種風格選項」放進對比，不展開細節。

風格特性評分對比#

下表用相對評分（★ 越多越強）幫助快速比較。沒有「最好」的風格，只有「最配合你優先特性」的風格。

注意「效能」分兩種：分散式風格的整體吞吐很高（高擴展），但單一請求延遲常因跨網路呼叫而變差。談效能務必先講清楚是哪一種，否則評分會誤導。

風格目錄結構示意#

不同風格在程式碼倉庫中長相截然不同，這也反映了它們的切分維度。

src/
├── presentation/      # 表現層：Controller、DTO
├── business/          # 業務層：Service、領域邏輯
├── persistence/       # 持久化層：Repository、DAO
└── database/          # 資料層：Entity、Schema

src/
├── core/              # 最小穩定核心：流程編排、外掛註冊
├── contracts/         # 外掛介面契約
└── plugins/
    ├── tax-us/        # 美國稅務外掛
    ├── tax-eu/        # 歐盟稅務外掛
    └── report-pdf/    # 報表外掛

services/
├── order-service/     # 各自獨立的倉庫／部署單元
│   ├── api/
│   ├── domain/
│   └── db/            # 各擁資料庫
├── payment-service/
└── inventory-service/

選擇決策#

選風格時，三個維度最關鍵：業務變動性、規模／並發、部署獨立性需求。

flowchart TD
    Start[選擇架構風格] --> Q1{需要各部分<br/>獨立部署/獨立擴展?}
    Q1 -->|否| Q2{邏輯是<br/>線性資料轉換?}
    Q1 -->|是| Q4{並發/吞吐<br/>是否極高?}

    Q2 -->|是| Pipe[管道架構]
    Q2 -->|否| Q3{變動點是否<br/>集中可插拔?}
    Q3 -->|是| MK[微核心架構]
    Q3 -->|否| Lay[分層架構<br/>最簡單的起點]

    Q4 -->|否| Q5{切分依據是<br/>業務能力?}
    Q4 -->|是, 讀寫密集| EDA[事件驅動]
    Q4 -->|是, 並發瓶頸在DB| SBA[空間導向]

    Q5 -->|是, 細粒度| MS[微服務]
    Q5 -->|偏整合既有系統| SOA[SOA]

    style Lay fill:#e8f5e9
    style MS fill:#e3f2fd
    style EDA fill:#fff3e0

選擇矩陣（依優先特性反查風格）：

不要因為「微服務很潮」就直接選它。對小團隊與不確定的業務，分層單體幾乎永遠是更好的起點——它最簡單，且保留了日後依演化原則再拆分的空間。

本章小結#