字數總計：0 個 | 閱讀時長：0 分鐘 |閱讀次數： 次

Clean Architecture 第33章：影片銷售系統案例研究

1. 案例研究的重要性

這章透過一個實際的影片銷售系統案例，展示了如何將 Clean Architecture 的原則應用到真實世界。這個案例特別重要，因為它：

  • 展示了如何從需求和業務邏輯出發進行系統設計
  • 說明了如何在實務中平衡架構原則和實際限制
  • 示範了好的架構如何支援系統演進

2. 產品概述

本案例探討一個線上影片銷售網站的系統架構設計：

  • 提供影片串流和下載服務
  • 支援個人用戶和企業用戶不同的授權模式
  • 個人用戶可以：
    • 付費串流觀看
    • 付較高價格永久下載擁有
  • 企業用戶限定：
    • 僅提供串流服務
    • 可購買批量授權並享有數量折扣

3. 架構設計的核心精神

3.1 從 Use Case 開始設計

系統設計的第一步是識別 actors 和 use cases，這反映了 Clean Architecture 重視業務規則的核心理念。

圖 33.1 Use Case 分析

Use Case Analysis

這張圖展示了系統的 Use Case 分析：

  1. 四個主要角色（Actors）
    • 清楚地展示了系統的主要使用者群
    • 每個角色都是系統變更的潛在來源
  2. 中心的抽象 Use Case
    • View Catalog 作為抽象 use case
    • 被 View Catalog as Viewer 和 View Catalog as Purchaser 繼承
    • 展示了如何處理相似但不完全相同的功能
    • 這種抽象能降低代碼重複，但保持足夠的彈性
  3. Use Case 的分布
    • 每個角色都有其特定的 use cases
    • 清楚顯示了每個角色的職責範圍
    • 有助於理解系統的整體功能範圍

圖 33.2 元件架構

Component Architecture

這張圖展示了系統的初步元件架構：

  1. 層次結構
    • 使用雙線表示架構邊界
    • 展示了典型的 Clean Architecture 分層：
      • Views（最外層）
      • Presenters
      • Interactors
      • Controllers（最內層）
  2. 依賴方向
    • 控制流程從右到左
    • 但大多數依賴箭頭指向左側
    • 符合依賴規則：所有依賴都指向包含更高層級策略的元件
  3. 特殊處理
    • Catalog View 和 Catalog Presenter 的特殊元件
    • 對應了圖 33.1 中的抽象 View Catalog use case
    • 使用抽象類別來實現基礎功能
  4. 部署彈性
    • 每個框代表潛在的 .jar 或 .dll 文件
    • 可以根據需求選擇不同的部署策略
    • 保持了架構的彈性

主要角色（Actors）：

  1. 觀看者（Viewer）
    • 觀看購買的影片
    • 瀏覽影片目錄
  2. 購買者（Purchaser）
    • 購買影片授權
    • 在企業情境中常與觀看者為不同人
  3. 作者（Author）
    • 提供影片檔案
    • 提供書面說明
    • 上傳輔助材料
  4. 管理者（Administrator）
    • 新增影片系列
    • 管理影片內容
    • 設定授權價格

特別注意：

  • 系統架構應該清楚展現這些 use cases
  • 例如 View Catalog 作為抽象 use case 的處理方式，展示了如何優雅地處理共用功能
  • 這種設計讓系統的意圖一目了然

3.2 分離的藝術

系統採用兩個維度的分離策略：

  1. 水平分離（Layers）
    • 基於 Clean Architecture 的同心圓架構
    • 由外而內依序為：
      • Views（視圖層）
      • Presenters（展示層）
      • Interactors（互動層）
      • Controllers（控制層）
    • 每層都有其明確職責
  2. 垂直分離（Actors）
    • 基於不同的角色進行分離
    • 確保對一個角色的改動不會影響其他角色
    • 反映了 Conway 法則：系統架構應映射組織結構

這種分離方式的優勢：

  • 每個元件都有明確的單一職責
  • 變更能被限制在特定範圍內
  • 支援多團隊並行開發
  • 提高了系統的可維護性和擴展性

3.3 依賴管理的實踐

本案例展示了如何具體實踐依賴規則：

  1. 控制流程
    • 從右到左流動
    • Controllers → Interactors → Presenters → Views
  2. 源碼依賴
    • 從左到右指向
    • 確保高層策略（業務規則）不依賴於低層細節
    • 使用開放封閉原則（OCP）維護正確的依賴方向

3.4 部署彈性的預留

架構設計提供了多層次的部署選項：

  1. 完全分離
    • 每個元件獨立部署為 jar/dll 檔案
    • 最大化彈性，但部署複雜度較高
  2. 按層級分組
    • 將相關元件組合成較大的部署單元
    • 例如：前端層、業務層、資料層
  3. 簡化部署
    • 可以簡化為前後端兩個主要部分
    • 適合小型專案或初期開發

重要的是：

  • 即使選擇合併部署，程式碼層面的分離仍然重要
  • 這種彈性允許系統根據需求演進
  • 體現了「保持選項開放」的原則

4. 實務考量與權衡

  1. 避免過度設計
    • 作者不主張教條式的完全分離
    • 承認可以根據實際需求調整部署策略
    • 強調架構的目的是服務業務需求
  2. 演進的支援
    • 架構設計應該支援系統隨時間演進
    • 允許在不同部署策略間轉換
    • 保持核心業務邏輯的獨立性
  3. 團隊協作
    • 架構設計考慮到開發團隊的組織結構
    • 支援多團隊並行開發
    • 明確的介面定義減少團隊間的衝突

5. 討論問題

  1. 為什麼作者選擇以角色（Actor）作為系統分割的主要依據？
  2. 這個架構如何體現了清晰架構（Clean Architecture）的核心原則？
  3. 在實際專案中，如何權衡元件拆分的粒度？
  4. 如何在保持架構彈性和降低複雜度之間取得平衡？
  5. 這種架構設計如何支援敏捷開發和持續交付？

6. 結論

本案例研究展示了：

  • 如何將抽象的架構原則落實到具體設計中
  • 好的架構如何支援系統的長期發展
  • 如何在理想架構和實務限制間取得平衡
在GitHub上在編輯此頁面
Table of Contents