# 系統架構，很多人其實是從錯的地方開始

很多團隊一開始談系統設計，就直接跳進技術。

討論 API 怎麼設計、資料庫怎麼切、要不要上 Kafka、要不要 microservice。

可是！
**如果大家對「我們到底在做什麼系統」沒有共識，技術討論其實很容易越講越歪。**

這也是為什麼我很喜歡 **C4 Model 的 Level 1（System Context Diagram）**。

它做的事情其實很簡單：
**先把大局講清楚。**

---

## Level 1 其實在回答一個很基本的問題

不是「系統怎麼做」，
而是：

> 這個系統，在整個世界裡面到底在哪裡？

換句話說：

* 它存在於什麼環境？
* 它負責哪一塊能力（Capability）？
* 它跟哪些人、哪些系統互動？

很多人會以為上下文是技術邊界，但其實不是。

上下文比較像是：
**組織怎麼理解自己的業務邊界。**

舉例來說，「電商系統」到底包含什麼？
訂單？會員？金流？物流？

如果團隊對這些事情的理解不一致，後面的架構圖通常會越畫越混亂。

---

## Level 1 的元素其實很少

一張 System Context Diagram 通常只有幾個東西：

**1️⃣ 核心系統**

放在中間，用黑盒（Black box）表示。
這一層不談內部怎麼做。

**2️⃣ 人（Persons）**

誰會用這個系統？
例如消費者、客服、營運人員等等。

**3️⃣ 外部系統**

像是金流服務、物流系統、CRM、或其他公司內部系統。

重點只有一個：

**誰跟誰互動。**

---

## 在這一層，我刻意不談技術

System Context Diagram 只關心兩件事：

* 什麼系統跟什麼系統在溝通
* 中間交換的是什麼資訊

至於 REST、MQ、Event、GraphQL 這些東西，其實都太早了。

當圖上開始出現一堆技術名詞，通常代表你其實已經在畫 Level 2 或 Level 3 了。

---

## 一些實務上我會注意的小地方

畫這類圖時，我會盡量讓它**一眼看懂**：

* 每張圖一定有清楚的標題
* 每個元素都有簡單描述
* 既有系統用灰色，新系統用藍色

我其實不太追求圖很漂亮。
我比較在意的是：

**一個沒參與專案的人，能不能 30 秒內看懂。**

---

## 如果邊界很難畫怎麼辦？

有時候會卡住。

像是你會開始想：

「這個算我們系統的一部分嗎？」
「還是其實是另外一個系統？」

這時候我通常會先畫 **Landscape Diagram**。

它比較像是一張「系統地圖」，
先把整個生態系畫出來，再慢慢決定邊界在哪裡。

---

## 為什麼我覺得 Level 1 很重要？

因為它其實在建立一件很關鍵的事情：

**Shared Mental Model（共同的理解）**

當技術人員、PM、甚至非技術主管
都能看著同一張圖說：「對，我們的系統就是這樣。」

後面的架構討論才會順。

不然很多時候其實只是
**大家腦袋裡有不同版本的系統，但以為自己在討論同一件事。**

---

如果你有在做系統設計，
其實很值得試試先畫一張 **C4 Level 1**。

很多模糊的地方，畫著畫著就會浮出來了。