Posted inAI AI Chatbot C4 Model

深入探討：理解C4模型的相互關聯與層次結構

為了使其可見，我們使用圖表。問題是？大多數圖表要麼過於抽象而無用，要麼過於細節而難以理解。

進入C4模型。由西蒙·布朗創建的C4模型，是一種用於可視化軟體架構的層次結構框架。它將系統分解為四個抽象層級：上下文、容器、組件和程式碼。

 

 

本文解釋了這些層級之間如何相互關聯，其關係性質（1:1、1:M 或深入探討），以及為何這種結構對有效溝通至關重要。

核心概念：層次抽象

C4模型的基本原則是抽象。它設計成類似於Google地圖的運作方式。
  • 當您查看世界地圖時，會看到大陸（上下文）。
  • 當您縮放時，會看到國家和城市（容器）。
  • 進一步縮放，會看到街道和建築物（組件）。
  • 完全縮放到極致，會看到單個磚塊（程式碼）。
這些層級之間的相互關聯並非水平的點對點關係；而是父-子分解.

層級之間的關係：1:M（一對多）

針對關係基數的具體問題，答案如下：C4層級之間的關係是「一對多」（1:M）分解。
  • 1個系統由多個容器.
  • 1個容器由多個組件.
  • 1個組件 由 …… 實現許多程式碼結構（類別/介面）。
這並非不是一一對應的關係。你不需要為每個類別都繪製新的圖表。相反地，你將類別分組為組件，將組件分組為容器，再將容器分組為系統。
這些層級之間的導航方式是深入檢視。利益相關者應能查看第1層的「容器」方框，並「深入檢視」到第2層，以了解該特定方框內的內容。

四個層級：結構與目的

以下是每一層的結構方式，以及它如何與下一層相連。

第1層：系統上下文圖

  • 它是： 最高層的抽象層。它將你的軟體系統顯示為中央的一個方框。
  • 主要元素： 你的系統、人類使用者，以及外部系統（例如：支付網關、電子郵件提供者）。
  • 目的： 用來說明「為什麼」和「誰」。適合非技術性利益相關者。
  • 與下一層的連結： 此處的中央「系統方框」是整個第2層圖表的父節點。

第2層：容器圖

  • 它是： 從第1層的系統方框進行放大檢視。
  • 主要元素： C4 中的「容器」並非指 Docker 容器。它指的是執行時期容器。範例：網頁應用程式、行動應用程式、微服務、資料庫、檔案系統。
  • 目的： 用來展示高階的技術選擇，以及系統主要部分之間的資料流動方式。
  • 與下一層的連結：這裡的每個「容器框」都會成為第三級圖表的邊界。

第三級：組件圖

  • 它是什麼：從第二級中放大查看特定的容器。
  • 主要元素：功能的邏輯分組。範例：控制器、服務、儲存庫、模組。
  • 目的：用來展示特定應用程式的內部結構。此圖供開發人員與架構師使用。
  • 與下一級的連結：每個「組件」均由第四級的程式碼實作。

第四級：程式碼圖（可選）

  • 它是什麼：放大查看一個組件。
  • 主要元素：類別、介面、函數、資料庫表格。
  • 目的：詳細設計。
  • 注意：此級別很少手動繪製。通常由 IDE 插件（如 IntelliJ 或 Visual Studio）自動產生，因為程式碼變動頻繁，無法維持手動圖表。

具體範例：電子商務平台

為了視覺化彼此的連結，讓我們追蹤一個電子商務系統透過各個層級。

第一級（背景）

  • 圖表：顯示一個稱為「電子商務系統」的框。
  • 關係：
    • 顧客 ->（使用）-> 電子商務系統
    • 電子商務系統 -> (發送付款至) -> Stripe API
  • 深入分析： 我們決定打開「電子商務系統」 框。

第二層（容器）

  • 圖示： 界限現在是「電子商務系統。」 內部，我們看到：
    • Web應用程式 (React/Node)
    • 資料庫 (PostgreSQL)
    • 電子郵件服務 (Python)
  • 關係：
    • Web應用程式 -> (讀取/寫入) -> 資料庫
    • Web應用程式 -> (發送請求) -> 電子郵件服務
  • 互連檢查： 這個Web應用程式 框這裡是一個子 的 電子商務系統 來自第 1 層。
  • 深入探查： 我們決定打開 網路應用程式 方框。

第 3 層（元件）

  • 圖示： 範圍現在是 網路應用程式. 內部，我們看到：
    • 登入控制器
    • 訂單服務
    • 產品儲存庫
  • 關係：
    • 登入控制器 -> (使用) -> 訂單服務
    • 訂單服務 -> (使用) -> 產品儲存庫
  • 互連檢查： 這個 訂單服務 元件在這裡是 子 的 網頁應用程式第2層的容器。

第4層（程式碼）

  • 圖示：由IDE為以下產生：訂單服務.
  • 元件： OrderController.java, OrderService.java, OrderEntity.java.
  • 連接檢查：這些類別共同實作第訂單服務第3層的元件。

連接性的關鍵概念

為了維持各層之間的完整性，你必須遵守三個關鍵規則：

1. 命名的一致性

如果你將一個方框命名為「行動應用程式」在第1層，它必須同樣命名為「行動應用程式」在第2層。如果你將其重新命名為「iOS客戶端」在第2層，你就會破壞讀者的心理模型。下探過程必須感覺順暢無縫。

2. 边界完整性

跨越父級邊界的關係必須在子級中予以考慮。
  • 範例： 如果第1層顯示系統 與Stripe，第2層必須顯示哪個容器與Stripe。在深入分析時，不能遺失外部連接。

3. 粒度管理

  • 第1層隱藏技術細節。（不要說「Java」，說「系統」）。
  • 第2層揭示技術細節。（說「Java Spring Boot 應用程式」）。
  • 第3層揭示邏輯結構。（說「驗證模組」）。
  • 混合不同層級是最常見的錯誤。不要在上下文圖（第1層）上顯示類別（第4層）。

這種結構的目的是什麼？

為什麼不直接畫一個包含所有內容的巨大圖表呢？

1. 管理認知負荷

人類大腦一次只能處理有限的資訊量。一個包含50個方框的圖表是無法閱讀的。C4模型將這50個方框分散到四個圖表中，每個圖表僅顯示5至7個與特定觀眾相關的關鍵元素。

2. 受眾區隔

  • 執行長／產品負責人： 只需要看到第1層。他們關心的是使用者和外部依賴，而不是你使用哪種資料庫。
  • DevOps/基礎設施： 需要看到 第2級。他們關心伺服器、資料庫和網路邊界。
  • 開發人員： 需要看到 第3級。他們關心程式碼在邏輯上的組織方式。

3. 活動文件

由於各級之間是解耦的，因此在重構程式碼時，您可以更新第3級（組件），而無需重新繪製第1級（上下文）。這使得文件能夠長期保持有效。

關係總覽

關係類型
描述
範例
垂直（級別之間）
分解（1:M）
一個系統 包含 許多容器。
導航
下探
點擊L1中的容器會導向L2。
水平（在同一級別內）
通訊/依賴
容器A 傳送資料給容器B。
實作
實現
程式碼（L4） 實現組件（L3）。

結論

C4模型不僅僅是畫方框；它在於整理思緒。各層之間的相互關聯是一種層次化下探，從一對多的分解開始。透過嚴格區分上下文、容器、組件和程式碼，您能確保每個圖表都有明確的目的和特定的受眾。
當您尊重這些層級之間的界限時，您便能將原本令人困惑的 spaghetti 圖表轉化為可導航的軟體環境地圖。

參考與工具

  1. 由 Visual Paradigm 提供的 C4 圖表工具 – 輕鬆可視化軟體架構：此資源介紹了一款工具，讓軟體架構師能運用 C4 建模技術，輕鬆創建清晰、可擴展且易於維護的系統圖表。
  2. 使用 Visual Paradigm AI 工具進行 C4 模型可視化的終極指南：本指南說明如何利用人工智慧自動化並增強 C4 模型的可視化，以實現更智慧的架構設計。
  3. 利用 Visual Paradigm 的 AI C4 Studio，簡化架構文件編制：探討經過人工智慧增強的 C4 Studio，讓團隊能創建乾淨、可擴展且高度可維護的軟體架構文件。
  4. C4 模型圖表入門指南：一份逐步教程，專為協助初學者在抽象的四個層級（上下文、容器、組件和程式碼）上創建 C4 模型圖表而設計。
  5. C4-PlantUML Studio 終極指南：革新軟體架構設計：本文探討如何將人工智慧驅動的自動化與 PlantUML 的彈性結合，以簡化軟體架構設計流程。
  6. Visual Paradigm AI 驅動 C4 PlantUML Studio 完整指南：一份詳細指南，說明此專業工作室如何將自然語言轉換為精確、分層的 C4 圖表。
  7. C4-PlantUML Studio：AI 驅動的 C4 圖表生成器：此功能概覽描述了一款 AI 工具，可直接從簡單的文字描述自動生成 C4 軟體架構圖表。
  8. 完整教程：使用 AI 聊天機器人生成與修改 C4 組件圖表：一份實作教程，示範如何使用 AI 驅動的聊天機器人，透過實際案例研究生成並優化 C4 組件圖表。
  9. Visual Paradigm 完整 C4 模型支援版本發佈：官方公告，宣布平台內全面支援 C4 模型，以管理多層抽象的架構圖表。
  10. C4 模型 AI 生成器：為 DevOps 與雲端團隊自動化圖表：本文探討對話式 AI 提示如何自動化完整的 C4 建模生命週期，確保技術團隊的圖表一致性與速度。