R3 Model

C4 model 是一個 2018 年之後發展出來的 架構描述方式。

我在 2017 年底也在組織內部弄了類似概念的表達架構方式 (稱 R3 Model)，很巧不巧，概念很 C4 model 很像，這段想法在我的著作 SRE實踐與開發平台指南 有提到，我在各種公開演講、部落格畫圖時的原則就是遵守 R3 Model 的思路。

底下整理寫在 FB 的原文。

R3 Model: 原文

紀錄跟朋友聊到系統架構的想法, 然後跟 C4 model 作比較.

我的觀點一直都是跟 #組織職責 對應的概念，也就是要談 #邊界 與 R&R (Role & Responsibility), 或者把 #康威定律 偷偷塞進去。無關於用什麼方式表達架構 (ex: C4 model).

我的邏輯源頭 OOP/D 的概念, interface & implementation, 封裝. 而 OOP 的 Class or Interface 我就會直接解讀成 R&R, 也就是誰 (Role) 應該做什麼 (Responsibility).

跟 C4 model 比較起來, 我的概念只有三層: 1) High Level View; 2) Logical View; 3) Physical View, 其實我這三層概念跟 C4 model 比起來差不多是前面三層: context, container, component.

High Level View

C4 的第一層 Context 跟我的 High level view 概念基本上 87 成一樣, 給非業務單位/老闆看的, 有定義使用者, 以及內外部系統依賴的概念. 我的表達則多了一層 ACL (Access Control), 表達各個系統之間的關係的操作性, 設計緣由則是 OOP 的 public / protected / private 這三個關鍵字, 代表可存取性與依賴性.

Logic View

C4 model 第二層稱為 Container, 我稱為 Logical View, 背後核心是展開系統的職責, 也就是 R&R. 常見的 Role 有 Web, Console, Database, Cache, Queue … etc. 每個 Role 之間同樣有依賴與 ACL (還是在描述 OOP 封裝的特性). 跟 C4 model 不一樣, 我設計的這個 view 會搭配 User Story / Scenario 一起看, 透過 Story or Scenario 來描述 Data Flow. 我的定義包含資料流的 #密度 (吞吐量) / #溫度 (頻率), 用來表述操作頻率與系統的重要性.

這樣設計的概念也有引用 敏捷經常討論的 Scrum Team, 一個 Scrum Team 要有 各種角色 (Roles), 像是 PO / Dev / QA / Ops / Designer … etc; 或者一個樂團要有歌手 / 吉他手 / 鼓手 / 貝士手 / 鍵盤手 … etc. 所以一個系統角色很多或很少, 代表 “架構” 的複雜度.

#Role 這個詞整個核心概念, 背後帶出的就是 Responsiblity, 在系統裡應該做什麼. 經常有人會討論 API Gateway, Load Balancer, Reverse Proxy 之間的差異? 這背後本質就是在討論 R&R. 看起來技術很像, 實際上在架構裡 (組織裡) 的 R&R 是不一樣的.

這個 Logical View (空間) 通常也是對內對外都可以拿來直接溝通討論使用, 需要了解技術的人可以看, 不太懂技術的人也可以看, 搭配 User Story, User Scenario (時間) 看.

這層的重點不是實作, 而是要對齊目標, 確認大家對於系統 / 業務的理解是一致的.

Physical View

C4 的第三層稱為 Component ，他這層跟我的 Physical View 概念就全然不一樣了. 我的說法是延續 Logical View, 往下深入已 Process 為概念展開, 可以對應到 K8s 的 POD 與 container 的想法, 簡言之就是很多人常說的 #部署架構 (Deployment Architecture). 也就是在 Logical View 中的每個角色, 實際上 runtime 都會有 N 個以上的副本, 基於這樣的考慮展開的架構.

這個結構 R&R 已經很清楚了, 只是可能會有多個副本. 就像 Scrum Team 裡可能會有多個 Dev or 多個 QA (這是癡心妄想?) 的概念. 同樣的會套用各種 ACL, 同時對應到更實際的成本問題.

Physical View 除了副本的概念, 更直接的就是談實作 / Solution, 例如 API Server 這個角色用 node.js/express, python/fastAPI, java/springboot … etc; database 則是用 MySQL/PgSQL, HA 作法; Queue 是 RabbitMQ / SQS / NATS …

這層更多是為了 Operation 做準備, 所有 O11y 都需要有這一層的資訊才能有效地展開, 否則 metric / logging / tracing 都會有遺漏. O11y 這個目的也是當時我設計這個三階層的動機之一.

第四層？

C4 model 還有第四層 Code, 我的設計沒有這一層. 當時我設計的時空背景是以 infra 的角度切入, 所以沒有針對 Code Level 做啥表示, 但順著上面三層的設計, 基本上搭配 sequence diagram / state machine 其實就很夠了.

命名

我沒有為我的方法取啥炫砲/簡潔的名稱, 當時 (2017?) 發想的起點都是從 OOP / 封裝切入, c4 model 是我這個 model run 好幾年之後, 套了數十個系統架構, 才知道有的東西.

跟個風就叫 R3 model 好了 XDDD

整個概念有整理在我的書裡, 三階有個名稱: 1) High Level View; 2) Service Definition; 3) Go Live

這概念應該只剩下我自己在用 XD

補充一個自問自答: 為啥我要自己造一個輪子？

A: C4 Model 發表於 2018 年，我構思 R3 Model 的時間約在 2017Q4，整個雛形完成在 2017/12 月，之後在公司裡從自己團隊的系統開始用這個方法，然後往外散。

我知道 C4 Model 大概已經是 2020 年，一個概念在網路上流傳起來到眾人皆知，三年差不多。所以不是為了造輪子，是當時的背景需要一個方法，有效「溝通」

圖示說明

下圖用 ChatGPT 畫的 R3 Model 概念 (v20260628)：

延伸閱讀

參考資料

Comments

▲ TOP ▲