我懂了，原來這就是4+1架構模型！

一個有效的架構描述需要做到以人為本，不同的利益相關方展示不同的視點及檢視。

那究竟需要從哪些視點入手，應該展示哪些檢視？這是個問題。

於是，1995年，Philippe Kruchten 在《IEEE Software》上發表了題為 The 4+1 View Model of Architecture 的論文，引起了業界的極大關注，在這個論文中，首次提出了使用 4+1檢視 來解決這個問題。

4+1 檢視

“4+1檢視” 從5個不同的側面來描述架構，其中包括4個主檢視和一個冗餘的場景檢視。4個主檢視分別如下：

• 邏輯檢視（Logical View）：主要是整個系統的抽象結構表述，關注系統提供終端使用者的功能。
• 程式檢視（Process view）：處理檢視關注系統動態執行時，主要是程式以及相關的併發、同步、通訊等問題。
• 物理檢視（Physical view ）：定義軟體到硬體的對映，反映架構的分散式特性。
• 開發檢視(Development View)：定義在開發環境中軟體的靜態組織結構。

在進行架構設計時，架構的各個關注點夠歸結於以上4個檢視，同時使用一個場景檢視對它們進行解釋和說明，就形成了第5個檢視，也就是4+1架構模型中的1。

在設計架構時，會基於每個檢視對系統進行獨立分解，每種分解都是基於這個檢視的關注點而進行的。基於每個檢視的分解都會使用相同的方法和步驟，把系統分解成元件並維持元件間互動的關係。但是每個檢視構成的元件型別各不相同，這些元件的型別源自檢視分解的需求。

01 邏輯檢視

用於描述系統的功能需求，即系統給使用者提供哪些服務；以及描述系統軟體功能拆解後的元件關係、元件約束和邊界，反映系統整體組成與系統如何構建的過程。

下面springcloud微服務的邏輯檢視示例（僅部分），就描述了springcloud中各個功能元件。從這個圖中，基本可以對springcloud有一個大顆粒度的瞭解。

02 物理檢視

開發出的軟體系統，最終是要執行在物理或軟體環境上。物理環境可能是伺服器、PC機、移動終端等物理裝置；軟體環境可以是虛擬機器、容器、程式或執行緒。部署檢視就是對這個部署資訊進行描述。在UML中通常由部署圖表示。

03 程式檢視

處理檢視，又稱過程檢視、執行檢視。用於描述系統軟體元件之間的通訊時序，資料的輸入輸出。在UML中通常由時序圖和流程圖表示，如下圖所示：

04 開發檢視

開發檢視關注的是架構如何指導開發流程，在這個檢視中，軟體系統會被分解成小的子程式或軟體包，併為每個子程式或軟體包定義介面。系統設計人員會根據這些分解的子程式和軟體包分配工作內容。

05 場景檢視

場景檢視是4+1架構模型中最重要的檢視，其他4個檢視都是以場景檢視為核心的。它用於描述系統的參與者與功能用例間的關係，反映系統的最終需求和互動設計。在UML中通常由用例圖表示：

小結

上面我們詳細介紹了4+1架構模型，但是在公司實際架構活動中往往都是會自定義一套符合公司架構標準的架構設計模板，然後根據特定專案進行裁剪或補充，那我們為什麼不直接使用上面提到的4+1架構模型進行架構設計呢？

個人覺得主要有三個方面的原因：

1. 系統複雜度增加：1995年提出4+1架構模型時系統大部分還是單體系統，現在基本是分散式系統的天下。4+1模型中的核心檢視場景檢視無法描述清楚整體業務。
2. 繫結UML圖：4+1檢視大部分繫結的是UML元素，顏值即正義，已經不符合今天的審美要求了。
3. 理解困難：4+1檢視的邏輯檢視、開發檢視、處理檢視比較容易混淆。