Day5_故事說完了，開始設計架構_C4 Contatiner

18th鐵人賽 c4 c4 contatiner 架構設計 mvc

Old Fashion

團隊HIT靈機一動萬象成章

2026-09-04 09:59:50

13 瀏覽

分享至

Day5_故事說完了，開始設計架構：C4 Container 與 Component

前言

前一篇整理完 User Story，我們已經知道 ProjectManagementWeb 要處理註冊、專案、Task Item、留言與權限等需求。但需求寫得清楚，不代表大家腦中想的是同一套系統。有人可能以為前端直接連資料庫，也有人可能把 Email 寄送寫在 Controller 裡。這些理解如果沒有先對齊，等到程式開始長大才會比較難拆。

這一篇先不寫程式。我會用 C4 Model 從系統全貌一路放大到後端 API 內部，畫出 Level 1：System Context、Level 2：Container，以及 Level 3：Component。這些圖是目前的設計草稿，代表預計採用的責任分工，等實作完成後還要回頭核對，不能把規劃圖當成現況圖。

先複習 MVC

在 ASP.NET Core 專案中，MVC 是常見的程式組織方式：

元件	責任
Model	表示資料與業務規則，例如使用者、專案及 Task Item。
View	顯示畫面，並接收使用者操作。
Controller	接收請求、呼叫對應邏輯，再決定要回傳的內容。

MVC 關心的是應用程式內部如何分工，C4 Model 則描述整套軟體系統。兩者觀察的範圍不同，所以 Controller、Service 或 Repository 可以是 Level 3 的 Component，卻不該直接被畫成 Level 2 的 Container。

C4 Model 在看什麼？

C4 可以理解成地圖的縮放層級。先確認系統位於什麼環境，再逐步看進應用程式內部：

層級	要回答的問題	圖中常見內容
Level 1：System Context	誰會使用系統？系統與哪些外部系統互動？	使用者、目標系統、外部系統
Level 2：Container	系統由哪些可執行應用程式或資料儲存組成？	前端 SPA、後端 API、資料庫
Level 3：Component	單一 Container 內有哪些主要責任單元？它們如何合作？	Controller、Service、Repository
Level 4：Code	元件實際由哪些程式碼組成？	Class、Interface、Method

不需要為了湊齊四個 C 而把所有圖都畫完。C4 官方也把 Component Diagram 視為選用項目；只有當它能協助開發者理解內部結構時才值得維護。ProjectManagementWeb 的後端同時包含授權、業務流程、資料存取與背景排程，這裡畫到 Level 3 是有幫助的。

Level 1：先看系統與外界

System Context Diagram 不討論 Vue、ASP.NET Core 或 SQL Server。這一層只回答兩件事：誰使用 ProjectManagementWeb，以及它依賴哪些不在我們控制範圍內的系統。

我先把四種身分合併成「系統使用者」，避免 Context Diagram 被角色細節塞滿。訪客可以註冊；登入後能做哪些操作，仍由系統角色與專案角色決定。這些權限差異會在流程、API 契約及測試案例中說明。

Level 2：C4 的 Container 不是 Docker Container

在 C4 Model 裡，Container 是需要執行的應用程式或資料儲存，例如 Single-Page Application、後端 API 或資料庫。它不等於 Docker Container，也不表示每個 Container 都要放在獨立主機。Docker 描述的是封裝與部署方式，C4 Container 描述的是系統責任邊界。

ProjectManagementWeb 目前規劃三個內部 Container，另有一個外部 Email 服務：

前端網站使用 Vue 3，負責畫面、路由、表單與操作狀態。
後端 API 使用 ASP.NET Core，負責身分驗證、授權及業務流程。
SQL Server 保存使用者、專案、Task Item、留言與個人狀態。
Email 服務位於系統邊界外，後端只透過明確介面呼叫它。

這張圖只談應用程式與資料儲存，不放頁面、Class 或資料表。Hangfire 若與 ASP.NET Core API 一起執行，仍屬於同一個 Container；將來若把背景工作拆成獨立 Worker，才需要更新 Container Diagram。

Level 3：放大後端 API

Component Diagram 一次只展開一個 Container。這次選擇後端 API，因為多數業務規則與外部相依都集中在這裡。前端網站、SQL Server 與 Email 服務仍會出現在圖上，但它們只是後端元件的協作者，不會在同一張圖裡繼續拆解。

這裡的 Component 是一組有明確責任的程式單元，不保證剛好對應一個 Class 或一個 .csproj。例如「應用服務」可能包含 UserService、ProjectService 與 WorkItemService；「Repositories」也可能有多個介面及實作。圖上刻意不列出每個類別，否則很快就會退化成難以閱讀、也沒人想維護的檔案清單。

依賴方向也需要留意。Controller 不應直接組 SQL，背景工作也不該複製一份 Task 到期判斷。兩者都呼叫應用服務，業務規則只有一份；Repository 與 Email Gateway 則把不穩定的資料庫及外部服務隔離在邊界上。這樣做不是為了套設計模式，而是讓規則能獨立測試，也讓外部服務失敗時有清楚的處理位置。