C4 model 是一個 2018 年之後發展出來的 架構描述方式，我在 2017 年底也在組織內部弄了類似概念的表達架構方式，很巧不巧，概念很 C4 model 很像，這段想法在我的著作 SRE實踐與開發平台指南 有提到，底下用 FB 寫的草稿，讓 ChatGPT 幫我整理的想法～

R3 Model：以角色與責任為核心的系統架構分層模型

在實務架構設計中，筆者長期關注的核心議題不僅僅是系統如何組合與部署，更在於這些系統元件在組織中的角色（Role）與責任（Responsibility）劃分。本文所介紹的 R3 Model，即是在此思維脈絡下逐步形成的一套架構視角，旨在協助團隊以一致的語意與責任邊界思考系統設計。

R3 Model 的核心觀點源自於物件導向設計（OOP）的封裝與介面觀念，並輔以康威定律（Conway’s Law）對組織結構與系統設計互為鏡像的洞見。模型共分為三層：

1. High Level View（高層次視圖）
2. Logical View（邏輯視圖）
3. Physical View（實體視圖）

以下針對各層做詳細說明。

1. High Level View：策略與邊界的呈現

High Level View 對應於 C4 Model 的 Context Layer，目的在於提供非技術利害關係人（如產品負責人、業務主管、決策者）一個宏觀且清晰的系統全貌。其主要包含：

• 使用者角色與互動關係
• 系統間的整合與依賴關係
• 存取控制（Access Control, ACL）設計

特別的是，R3 Model 在此層明確引入 ACL 的概念，靈感來自 OOP 中的 public、protected、private 權限修飾詞，藉以呈現不同系統元件之間的依賴強度與邊界彈性。此舉有助於促進治理層面的討論，例如系統間是否應建立明確 API 合約、資料是否應有等級存取等。

2. Logical View：系統角色與責任的定義

Logical View 對應 C4 Model 的 Container Layer，然其設計目標更偏重於揭示 系統內部職責的合理劃分，而非僅僅著眼於運行時的容器部署。其關注焦點包括：

• 系統角色分類：Web、API Gateway、Database、Queue、Cache 等
• 各角色的責任範疇與 ACL 規則
• 搭配 User Story 或 User Scenario，描繪資料流的走向與行為密度

本層設計亦受敏捷開發團隊組成啟發：如 Scrum Team 中的 PO、Dev、QA、Ops、Designer 等多元角色，系統亦應具備清晰的「誰該做什麼」配置。

此外，筆者進一步將資料流的特性定義為：

• 資料密度（Density）：代表資料處理的吞吐量需求
• 資料溫度（Temperature）：代表資料互動的頻率或即時性

透過這樣的維度，架構師與業務人員能更直觀地理解每個子系統的重要性與資源配置優先順序。

本層的設計核心，在於建立跨部門對齊的語意圖譜，以利溝通與討論，而非立即導向實作技術。

3. Physical View：落實部署與營運觀點

Physical View 在概念上並非完全等同於 C4 的 Component Layer，而更接近於部署層級（Deployment Architecture）與營運可行性分析。本層的設計聚焦於：

• 各邏輯角色的部署實例數（副本）、伸縮策略與監控點配置
• 實作技術選型：如使用 Spring Boot、FastAPI、Node.js，資料庫採用 MySQL、PostgreSQL，訊息中介為 RabbitMQ、SQS、NATS 等
• Infrastructure 與 Observability 架構的結合，例如搭配 Prometheus/Grafana、ELK Stack、Tracing 工具等

此層的設計使得系統可以與運維層有效對接，並作為 DevOps 團隊針對容量規劃、可用性分析、資安設計等核心議題的工作依據。

R3 Model 發展初衷之一，即為解決觀測性不足所導致的部署與維運斷層問題。

關於 Code Layer 的補充

相較於 C4 Model 的第四層 Code Layer，R3 Model 並未進一步延伸至原始碼層級。此設計選擇源於筆者於設計本模型時，主要視角為系統架構與基礎建設層，並非針對單一服務的程式細節。然而，若需補足此層，亦可透過：

• Sequence Diagram（時序圖）
• State Machine Diagram（狀態機）

來進行行為與狀態的補充建模，支撐跨服務協作或狀態變化之設計需求。

命名與緣起：R3 Model 的實務脈絡

R3 Model 並非源自於既有理論，而是在筆者於 2017 年左右，歷經多個實務系統架構案中逐步形成與歸納。直到多年後接觸到 C4 Model 時，才發現兩者前三層有高度相似性。

為求記憶與溝通方便，筆者將其命名為 R3，意指：

1. High Level View — 界定邊界與溝通語意
2. Service Definition (Logical View) — 描述系統責任分工
3. Go Live (Physical View) — 對應部署與營運策略

目前此模型已在多個系統設計與導入中實證可行，並持續迭代中。雖未有廣泛使用者，但對於具有 Infra 或架構主導責任的工程師與架構師而言，R3 Model 可視為一套清晰的架構推演工具。

圖示說明

以下圖像呈現 R3 Model 的三層架構概念：

如果你對此模型有共鳴，或希望引入團隊實踐中，歡迎交流與討論，或協助擴充此模型在其他場景的應用。

延伸閱讀

參考資料

• 康威定律：系統設計如何映照組織結構
• C4 Model 官方介紹