設計分散式系統需要清晰性。當架構依賴非同步通訊時，視覺化資料流變得複雜。C4模型提供了一種結構化的方法來記錄軟體架構。然而，標準的C4圖表經常難以呈現事件驅動架構（EDA）的細微差別。本指南探討如何調整C4關係線，以準確呈現事件流、生產者與消費者，且無歧義。我們將著重於語義精確性，確保利益相關者能一目了然地理解系統行為。
為何標準C4需要針對EDA進行調整 🤔
傳統的C4圖表擅長使用實線來展示容器之間的資料流動。在同步請求-回應模式中，這是很直覺的。請求進入，回應產生。事件驅動架構引入了一層間接性。生產者發出事件，一個或多個消費者稍後處理它。這種連接通常較為鬆散，且時序是解耦的。
- 同步流：呼叫者等待結果的直接呼叫。
- 非同步流：發出後即不管的事件，生產者不會等待。
- 推送對拉取：服務是主動發送資料，還是主動取得資料？
使用標準實線來表示事件串流，可能會誤導讀者認為連接是同步的。這在故障排除或新成員入職時會造成混淆。為解決此問題，我們必須調整關係線的視覺語言。
理解事件情境下的C4層級 🏗️
在繪製線條之前，我們必須理解它們所連接的方框。C4模型的每一層都針對不同的受眾與抽象層級。
1. 上下文層級：整體概觀 🌍
在最高層級，您定義系統邊界。在事件驅動系統中，系統通常是由一組對外部觸發做出反應的服務組成。
- 人員：觸發動作的使用者（例如，點擊按鈕）。
- 外部系統：第三方API或遺留系統提供資料輸入。
- 系統：所有事件生產者與消費者的總和。
此層級的關係線應著重於整合點。如果人類點擊按鈕，這是一項請求；如果支付網關發送webhook，這就是一個事件。在上下文層級區分這些，可避免對觸發系統的來源產生混淆。
2. 容器層級：服務與串流 💻
這裡正是關鍵所在。容器代表可部署的單元（應用程式、資料庫、佇列）。在EDA中，此層級必須顯示服務如何與訊息代理或其他服務溝通。
- 應用程式容器：處理業務邏輯的微服務。
- 資料容器： 資料庫或事件儲存庫。
- 佇列/主題容器： 作為中介者的訊息代理。
這裡的關係線至關重要。它們代表了事件通道。實線表示直接的 API 呼叫。虛線表示事件訂閱。此區別對於開發人員理解延遲和可靠性至關重要。
3. 元件層級：內部邏輯 🧩
在容器內部，元件負責特定的職責。在事件驅動架構（EDA）中，元件通常包括事件監聽器、處理器和轉換器。
- 事件監聽器： 等待傳入訊息的元件。
- 處理器： 轉換事件資料的元件。
- 儲存庫： 持久化狀態變更的元件。
此層級的關係線顯示服務內部的資料流。它們幫助開發人員追蹤事件如何轉換為資料庫更新。
事件驅動架構中關係線的語義 📏
架構圖中最常見的錯誤來源是線條樣式的模糊不清。在 C4 模型中，線條通常代表資料流。在 EDA 中，我們需要區分控制流與資料流，以及同步與非同步。
定義線條樣式
| 線條樣式 | 含義 | 使用案例 |
|---|---|---|
| 實線 | 同步呼叫 | API 請求 / HTTP 呼叫 |
| 虛線 | 非同步事件 | 訊息代理訂閱 |
| 雙線 | 雙向同步 | 請求/回應模式 |
| 曲線 | 事件串流 | Kafka / 主題訂閱 |
標記關係
線上的標籤提供上下文。一個通用的「資料」標籤是不夠的。應明確指出協定以及方向.
- HTTP POST：表示同步推送。
- WebSocket：表示持久連接。
- 事件：OrderCreated：指定事件類型。
- 主題：Orders：指定邏輯通道。
標記時應避免使用模糊的詞語。不要使用「資料流」，而應使用「訂單事件」。這能降低讀者的認知負擔。
常見模式及其圖示表示 🔄
事件驅動架構遵循特定模式。每個模式在C4模型中都有獨特的視覺表示方式。理解這些模式有助於建立一致的文件。
1. Pub/Sub（發佈/訂閱）
在此模式中，生產者將事件發送到代理。消費者訂閱主題。
- 視覺呈現： 從生產者到代理的虛線。從代理到消費者的虛線。
- 標籤： 「主題：InventoryUpdates」。
- 含義： 生產者不知道哪些消費者存在。
2. 事件上的請求/回應
一個服務發送事件並等待回應事件。這通常用於長時間運行的操作。
- 視覺：實線連接到代理。虛線從代理返回。
- 標籤：「請求：計算稅款」→「回應：稅款計算」。
- 含義：帶有回調的非同步通訊。
3. 事件來源
狀態是從事件存儲中存儲的事件序列推導出來的。
- 視覺：容器連接到事件存儲容器。
- 標籤：「追加事件」。
- 含義：真實來源是日誌，而不是當前狀態。
4. CQRS（命令查詢職責分離）
寫入模型與讀取模型的分離。命令更新狀態；查詢讀取狀態。
- 視覺：兩個不同的路徑。寫入路徑（命令處理器）對比讀取路徑（讀取模型）。
- 標籤：「命令：建立訂單」對比「查詢：獲取訂單詳情」。
- 含義：針對不同類型的存取進行優化。
應避免的陷阱與反模式 ⚠️
即使使用正確的工具，錯誤仍會發生。在事件驅動架構的C4建模中常見的錯誤可能導致架構偏移或誤解。
- 過度抽象：在上下文層級繪製過多連接。保持上下文層級簡單。僅顯示主要的整合。
- 同步與非同步混用：對非同步呼叫使用實線。這會讓開發人員對延遲期望產生混淆。
- 遺漏錯誤流程： 圖表通常只顯示順利的流程。請包含錯誤處理、重試或死信佇列的線路。
- 忽略資料一致性： 忽略顯示資料儲存的位置。在事件驅動架構中，最終一致性至關重要。請顯示真實來源的位置。
- 線路過多： 一個「意大利麵圖」毫無用處。如果圖表中關係超過 20 個，建議按領域拆分。
工具與維護考量 🛠️
繪製圖表僅完成了一半的工作。維護圖表至關重要。如果圖表與程式碼不符，就會產生文件債務。
版本控制
將圖表檔案與程式碼儲存在同一個程式庫中。這樣可確保新增功能時，圖表也能在同一個提交中更新。
自動化
某些工具可從程式碼註解生成圖表。這能降低維護負擔。然而，仍需手動審查以確保語義正確性。
協作
圖表是溝通工具。應由架構師、開發人員和產品經理共同審查。回饋可確保視覺語言與團隊的思維模型一致。
深入探討：元件層級關係 🧱
在事件驅動架構中，元件層級經常被忽略。這裡是事件處理邏輯所在的位置。清晰的關係有助開發人員理解內部耦合。
事件處理常式
事件處理常式是監聽特定事件的元件。在圖表中，這是一個位於容器內的方框。
- 輸入：進入的事件資料。
- 輸出：資料庫寫入或新事件。
- 關係： 使用虛線來表示觸發。
領域服務
這些元件包含業務邏輯。它們通常由事件處理常式觸發。
- 輸入：來自事件處理常式的資料。
- 輸出：狀態變更或通知。
- 關係： 內部方法調用使用實線。
外部整合
有時，組件會在事件處理過程中調用外部 API。
- 輸入：事件載荷。
- 輸出：API 回應。
- 關係：帶標籤的實線，標籤顯示協議（例如：REST、GraphQL）。
為未來演進而設計 🚀
架構會變更。新的服務會被加入，舊的服務會被停用。你的圖表應支援這種演進，而無需完全重繪。
模組化圖表
不要只畫一個巨大的圖表，而是建立一組專注的圖表。一個用於「訂單領域」，一個用於「支付領域」。這樣可以讓關係線保持可控。
標準化符號
與團隊協定一套符號標準。如果一位開發者用虛線表示事件，另一位用實線，文件將變得難以閱讀。應為關係線定義一套風格指南。
文件生命周期
將圖表更新納入「完成定義」。如果代碼變更引入了新的事件，圖表必須在同一個拉取請求中更新。這確保文件始終是真實資訊的來源。
最終考量 📝
使用 C4 模型來建模事件驅動架構需要細心。標準關係並不足夠。你必須明確地使用線條樣式和標籤來定義流動的性質。這種清晰度能降低風險並提升團隊溝通。
透過調整 C4 的關係線，你會建立一種能反映系統非同步特性的視覺語言。這有助於利益相關者理解延遲、可靠性與資料一致性。應著重精確性而非美觀。清晰的圖表勝過華麗的圖表。
請記住，圖表是活文件。它們會隨著系統演進。定期審查可確保視覺呈現始終準確。這種有紀律的方法能帶來更好的系統設計與更易維護的結果。
重點總結
- 區分同步與非同步：為不同的流程使用不同的線條樣式。
- 明確標示：避免使用「資料」等泛泛的詞語。
- 專注於領域：將大型系統拆分成可管理的圖表。
- 保持一致性：確保圖表與程式碼一致。
- 讓團隊參與：將圖表用作溝通工具，而不僅僅是文檔。
實施這些實踐將帶來穩健的架構文檔策略。它能支援事件驅動系統的複雜性，同時不會讓讀者感到負擔。清晰是目標，精確是方法。