對程式設計師來說，架構是一個常見詞彙。如果想成為一名架構師，對架構概念的理解必須清晰。否則，在制定架構方案時，肯定會漏洞百出，問題頻發，這將對你的面試、晉升和團隊領導產生負面影響。
我們看下維基百科關於架構的定義：
軟體架構是抽象描述系統的一組結構，以及構建這些結構的規則。這些結構包括：軟體要素、要素之間的關係以及它們的屬性。
在這個定義中，核心概念為系統、要素、關係。
系統
在軟體架構中，"系統"是指由多個相互作用的部分組成的複雜整體，這些部分共同完成特定的功能或任務，而架構設計就是對某個系統的抽象描述。
要素
“要素”是構成系統的基本單元，通常有子系統、模組、元件。
- 子系統是一個較大系統的一部分，具有特定的功能責任，通常可以獨立於整個系統操作。每個子系統可以包含多個模組或元件，且通常圍繞特定的業務領域或技術功能進行組織。
- 模組是軟體架構中的邏輯單元，它封裝了一組相關的功能或服務。模組通常透過定義良好的介面與其他模組互動，支援高內聚和低耦合的設計原則。
- 元件是自包含的、可程式設計的、可重用的、與語言無關的軟體單元，軟體元件可以很容易被用於組裝應用程式中，是可以獨立完成部署的最小單元。
可能有人對模組、元件的概念比較懵。簡單來說，模組是從業務邏輯維度上的劃分，元件是從技術維度上的複用。下面還會用一個例子說明它們的區別。
關係
”關係“指的是系統中各個要素（如子系統、元件、模組、類等）之間的連線和互動方式。這些關係定義了要素如何協作，以及它們如何共同實現系統的功能。
我們以新零售SaaS系統為例，解釋一下各個概念：
- 子系統包括：線上商城子系統、POS收銀子系統、訂單管理子系統、商品管理子系統、客戶管理子系統、倉儲管理子系統、配送子系統、中央庫存子系統、客服子系統、採購子系統等。
- 訂單履約系統，從業務維度可劃分為以下模組：C端履約服務模組、訂單派單模組、訂單管理模組、揀貨管理模組、發貨管理模組、逆向履約模組等。
- 訂單管理模組從技術維度上，依賴Mysql、Redis、Elasticsearch、安全元件等技術元件。
- 各子系統、各模組、各元件都可能產生關係，透過協作關係共同完成系統功能。
架構的檢視與視角
在工作當中，我們經常會聽到以下說法：
- 產品負責人說，現在的業務架構太複雜，需要仔細梳理一下。
- 技術領導說，這個專案很複雜，需要做下架構方案評審。
- 研發經理說，這次秒殺活動方案，需要用到高併發架構方案。
- 一線研發說，網際網路大廠都會用到微服務架構，我要學好微服務。
上面提到的架構到底是指什麼？這些說法究竟對還是錯？
其實上面的說法都是對的，只是採取的視角不一樣。
因為複雜系統涉及的利益干係人眾多，例如：客戶、產品經理、研發、銷售、運營、管理層等。由於背景不同，認知不同，每個人看待系統的角度、方法都不相同。
為了控制複雜度，我們需要設計一整套架構描述物，並且為它們做好分類和定義，讓每種架構描述物都有自己的側重，讓每個利益干係人都能快速獲取關注的資訊。
為了達成這個目標，首先需要理解檢視與視角的概念。
架構視角
什麼是視角？大白話就是你站在什麼地方看。
我們以城市系統為例，你站在城市的某條馬路上，能看到什麼？
能看到幾座樓房，幾排樹木，幾條大馬路，熙熙攘攘的一些人。
但是你坐在飛機上看，能看到什麼？
能看到一片片的樓盤，能看到群山，能看到江河湖海。所以，你能看到什麼和你站在什麼地方看有很大關係，同時也會影響你看待事物的粒度。
如果把視角比作一個座標點，那它需要一套座標系，座標系通常有4個維度：廣度、深度、檢視型別、時間。
廣度是指看待事物的寬度，以業務流程為例，根據出發點不同，有時需要看一個部門內的流程，有時需要看多個部門的協作流程，有時需要看端到端跨部門的流程。
深度是指看待事物時，要到達哪個細節層次，例如看業務流程，需要看到組織級、部門級、還是某個崗位的具體操作步驟。看軟體系統，需要看到系統級、模組級、還是一行行的程式碼。
廣度和深度一般是相互影響的，如果看待事物的廣度越寬，那麼層次就會越抽象，這和組織架構的設計也是相輔相成的，一般高層管理者看問題非常全面，但對細節不關注，一線執行人員，對問題的細節非常瞭解，但視角卻非常窄。
檢視型別是為利益干係人量身打造的一組關注點的集合，下文中會詳細介紹。
時間維度比較好理解，就是看待事物的時間點，過去、現在、還是未來。
架構檢視
什麼是檢視？大白話就是你想看到什麼。
檢視是為利益干係人量身打造的一組關注點的集合。
同樣以城市系統為例，想要趕早高峰的上班族，他的關注點是哪條路線最快，因此他需要一副地鐵公交路線圖。
想要租房的租客，他的關注點是公司附近有哪些小區，租金多少，因此他需要一副租房地圖。
想要疏通下水道的工人，他的關注點是下水道是怎樣排布的，因此他需要一副下水道的排布圖。
同一個城市系統，不同角色的關注點是完全不一樣的，想要獲取的資訊也是完全不一樣，如果把所有資訊雜糅在一起，不做檢視隔離，導致的結果就是資訊太龐雜，每個人都很難獲取想要的資訊。
同理，不同干係人看待軟體系統的關注點也是迥然不同的，為了把不同人的關注點區分開，誕生了很多軟體檢視的分類方法，比較著名的有“4+1”檢視，TOGAF的業務架構、應用架構、資料架構、技術架構等檢視分類法。
我們重點說下TOGAF的檢視型別：業務架構，應用架構，資料架構，技術架構。
其中業務架構是靈魂，應用架構，資料架構，技術架構都是支撐業務架構而存在的，後三者也統稱IT架構。
- 業務架構：為了實現企業的業務戰略，企業將自身業務結構化表達為全面的、多維度的抽象模型，包括：業務能力、端到端的價值交付、資訊和組織結構，它們之間的關係，以及它們與戰略、產品、策略、專案執行、利益干係人之間的關係。
- 應用架構：基於業務架構，設計出應用系統的層次結構，包括系統、應用、模組、元件等構件的劃分規範，它們的定義、邊界、相互間的互動協議，以及它們和業務活動的關係。
- 資料架構：資料架構描述了一系列的模型、策略、規則、標準，它們決定資料如何獲取、如何儲存、如何分佈、如何整合，以及資料如何在系統和組織中使用。資料架構是企業架構中非常重要的一塊架構領域，通常包括3個架構過程，概念模型設計（設計業務概念模型）、邏輯模型設計（設計模型間的邏輯關係與自身屬性）、物理模型設計（設計資料的技術實現細節）。
- 技術架構：技術架構描述了一系列的可部署的軟體包、硬體能力，以及它們之間的協作關係，透過它們可以支撐起企業對業務、資料、應用服務的需求，它們包括但不限於IT基礎設施、中介軟體、網路、通訊設施、運算能力、硬體標準等。
透過檢視與視角，我們可以分離關注點，將複雜問題進行拆解，讓每個區域性的複雜度控制在一個可以接受的範圍。
同時，團隊有了統一的認知座標系，進一步促成了業務標準化，以業務標準化為基礎，透過分離不變點與變化點，提煉出可複用的元件，快速響應業務需求變化。
本文已收錄於，我的技術網站：tangshiye.cn 裡面有，演算法Leetcode詳解，面試八股文、BAT面試真題、簡歷模版、架構設計，等經驗分享。