一張架構圖，描述的不只是系統，更反映了設計者的思考方式。

架構分析先理解設計，而不是急著找問題

前一章提到，架構師閱讀架構圖時，關心的不只是圖上畫了哪些元件，更重要的是理解資料如何流動、系統如何建立關係，以及整個架構是否已經完整描述了設計者的想法。

因此，在實務工作中，架構分析並不是單純檢查圖面上的元件是否齊全。同一張架構圖，可能已經清楚呈現設計者想表達的內容，也可能因為資訊不足，而讓閱讀者無法理解某些重要的設計決策。

這也是架構分析經常遇到的情況。看到一張架構圖時，我們很容易注意到 WAF、監控、備份或高可用性等「已經畫出來或沒有畫出來」的元件，卻忽略了圖面背後還有許多尚未說明的設計關係。

例如，一條連線究竟代表什麼資料流？系統之間如何驗證身分？哪些區域屬於不同的信任邊界？某個元件為什麼需要直接連線到另一個系統？而圖上沒有呈現的部分，又究竟是設計上不存在，還是只是尚未描述？

下面這張圖，就是一個典型的例子。

圖 14-1　案例架構圖（示意圖）

假設今天有一位開發人員拿著這張架構圖，希望架構師協助進行架構分析。面對這樣的架構圖，我通常不會急著按照上面的內容直接提供建議，而是會依照幾個不同的角度，逐步確認是否已經完整描述了整個系統。

有哪些方式可以訪問系統？

閱讀架構圖時，我通常會先從系統入口開始，因為這通常是系統服務的起點。

這張圖中可以看到，同一個入口延伸出兩條不同的流量路徑，而且兩條路徑各自經過不同的安全控制。然而，架構圖並沒有說明流量是依據什麼條件進入不同路徑，也沒有描述這兩條路徑各自承載哪些服務。

因此，比起判斷哪一條路徑比較合理，更重要的是先確認整個流量設計是否已經被完整描述。例如：

• 使用者是在什麼情況下進入不同的路徑？
• 是依據網址、功能、來源位置，還是不同的服務？
• 兩條路徑是否都經過相同的安全控制？
• 是否存在某一條路徑沒有受到相同程度的保護？
• 也許不同的通訊協定會走不同的路徑，但是否也針對不同的來源建立了相對應的存取控制？

如果這些資訊沒有交代清楚，就很難理解整個系統如何對外提供服務，也無法確認安全控制是否真正涵蓋所有入口。

每一個元件，都應該有存在的理由

理解整體流量之後，接著會開始閱讀各個元件在架構中的角色。

例如圖中的 NAT Gateway 出現在架構圖的右上角，但目前沒有任何資料流與它建立關聯，也沒有說明哪些系統會透過它進行對外連線。

遇到這種情況，我通常不會直接認定設計有問題，而是會先確認這個元件存在的原因。例如：

• 哪些服務會透過 NAT Gateway 存取外部資源？
• 它是目前正式使用的元件，還是預留未來擴充？
• 是否只有部分流程尚未畫出來？
• 如果移除這個元件，是否會影響現有系統的運作？

這些問題除了協助確認架構圖是否完整，也是在確認每一項架構決策是否仍然具有實際價值。

因為在企業環境中，一個沒有被使用、沒有明確目的，或已經被其他能力取代的元件，並不只是架構圖上的一個「多出來的方塊」。它可能代表額外的雲端資源、授權費用、維運工作以及後續的管理負擔。這些成本有時候不容易在單一系統中被察覺，卻會隨著環境規模逐漸累積。

因此，架構師在閱讀元件時，不只是確認「它有沒有問題」，也需要理解為什麼需要它、它解決了什麼問題，以及它所帶來的成本是否仍然合理。

如果一個元件已經出現在架構圖裡，卻無法從資料流或系統流程理解它的角色，就表示這部分的設計資訊仍然需要進一步確認；而如果確認後發現它已經沒有實際用途，則更應該思考是否可以移除，避免架構持續累積不必要的複雜度與成本。

資料流是否完整？

前一章提到，我習慣從資料流開始理解架構，因此當資料流在某個地方突然中斷時，就值得進一步確認後續設計。

例如圖中可以看到 Redis 與 PostgreSQL，但目前沒有任何箭頭連接這兩個元件，因此無法判斷哪些服務會讀寫資料，也無法理解資料生命週期。

真正需要確認的，不只是資料庫本身，而是資料如何流向資料庫，又如何提供其他系統使用。例如：

• 哪一個服務會寫入 Redis？
• PostgreSQL 儲存哪些資料？
• 是否還有其他沒有畫出的資料流？
• 不同系統是否共用相同的資料來源？

只有把資料流補完整，後續才能繼續討論資料加密、備份、權限管理、資料分類以及法規遵循等設計。

系統之間如何互動？

除了資料流之外，我也會觀察系統彼此如何建立關係。

許多架構圖習慣使用雙向箭頭，但雙向箭頭真正代表的意思卻不一定相同。有些代表 請求（Request）／回應（Response），有些代表同步，有些則代表事件通知，甚至有些只是表示兩個系統彼此可以通訊。

不同的互動方式，代表完全不同的架構設計，因此仍然需要確認許多細節。因此，仍然需要進一步確認：

• 誰是流程的發起者？
• 流程如何開始？
• 哪一個系統負責控制整個流程？
• 是否需要身分驗證？
• 是否跨越不同的信任邊界？

如果這些資訊沒有描述清楚，即使所有元件都已經畫出來，也很難真正理解整個系統的運作方式，更無法評估後續可能帶來的安全、治理或維運影響。

架構圖需要完整表達設計

從前面的案例可以看到，架構分析並不是急著評論設計是否正確，也不是一開始就找出所有可能的問題，而是先理解設計者希望透過架構圖表達什麼，以及目前呈現的資訊是否足以支撐這樣的理解。

閱讀一張架構圖時，架構師通常會逐步理解幾個關鍵問題：流量如何進入系統、各個元件分別負責哪些工作、資料如何在不同系統之間流動，以及系統彼此如何建立互動關係。這些資訊彼此是連結的，缺少其中一部分，就可能影響對整體設計的理解。

因此，架構分析過程中需要補充的，不一定是新的元件，也可能是資料流向、系統關係、信任邊界或設計決策等尚未清楚描述的資訊。先把設計脈絡理解完整，後續才有足夠的基礎討論安全控制、治理要求、維運方式以及風險。

小結

架構圖提供的是理解系統的入口。架構師透過元件、資料流、系統關係與互動方式，逐步建立對整體架構的理解，而不是只從圖面上確認有哪些技術元件。

在閱讀過程中，除了已經呈現的內容，也需要留意那些尚未被描述的部分。某個元件沒有出現在圖上，並不一定代表系統沒有這項能力；一條資料流沒有被標示，也不代表系統不存在這樣的互動。這些「沒有被說明的地方」，往往需要進一步與設計者確認，才能真正理解架構背後的設計意圖。

因此，架構分析不只是閱讀架構圖上的內容，更是透過圖面逐步建立對系統的整體認知，並從資料流、系統關係與設計決策之間的連結，找出需要進一步討論與確認的地方。

當不同角色都能以相同的架構資訊理解系統時，架構師、開發人員、維運團隊與資安人員才能在共同的認知基礎上討論設計、評估風險，以及後續需要補強的架構能力。