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