概念解析
在文章開始之前需要先了解幾個概念：
-
什麼是方法論？
我們拿到一個輸入，然後根據這個輸入預期一個輸出，把中間這個過程描述出來就是方法論。是以我們本篇講的架構師方法論就是架構師先拿到經過需求分析出來的輸入，然後完成架構設計，這個過程就是架構設計方法論。
-
什麼是設計？
設計是實作意圖的書面表現形式，而非口頭的東西；
設計是要讓實作者能了解設計者的意圖，是給别人看而非自己看；
設計是要讓不同的實作者做出來的東西差不多；
設計是嚴肅的，後續實作者不能随意偏離設計
-
什麼是系統架構師
作為系統架構師你需要跳出代碼層面的設計，站在更加宏觀的角度進行把握。
你關注的是整個系統而不是其中的一兩個查詢子產品，你看到的元素更多的是 ：人 、硬體 、軟體 、網絡。
業務分析
業務分析概述
- 業務分析是在系統開發之前對系統要解決的業務領域的研究過程，目的是搞清楚該業務領域的概念以及業務的運轉過程
- 開發系統的目的一般是為了優化業務流程，使業務運轉得更加高效、經濟
- 系統的價值主要在于實施後能夠幫助客戶帶來多少業務價值
- 不管有無系統，業務通常是不變的
業務分析階段活動模型
業務分析階段是由業務分析師 基于自身的業務知識和類似産品的參考，再結合客戶、領域專家的咨詢和指導輸出業務分析階段的成果，主要包括 領域模型 和 業務模型
領域模型
領域模型是對領域内的概念類或現實世界中對象的可視化表示。又稱概念模型、領域對象模型、分析對象模型。它專注于分析問題領域本 身，發掘重要的業務領域概念，并建立業務領域概念之間的關系。概念比較深奧，其實說白了就是我們把基于對業務的了解畫成一個類圖，并畫出這些類之間的關系（面向對象），下面我們看一個實際的領域模型然後加深一下了解。
在領域模型繪制時經常會出現下面兩種典型錯誤：
-
将待開發系統也放在領域模型裡面
待開發系統要不要出現在領域模型中取決于你的業務離開待開發的系統能不能玩的轉。舉個例子：如果開發的是共享單車的資訊系統，共享單車離開資訊系統肯定玩不轉，是以這時候資訊系統需要出現在領域模型。
-
概念劃分不清，關系沒有畫到位
比如屬性畫成了類，繼承關系搞錯
領域模型的作用
領域模型可以整理業務中的概念以及關系，幫助團隊中的成員對業務的了解保持一緻；往後可以指導資料庫設計、系統功能設計、指導開發。
現在有種開發模式是基于UI指導開發，根據UI進行資料庫資料庫設計、代碼編寫，我們稱之為 “急功近利式” 開發模式。因為UI是系統表面性的東西，是異變的，不穩定的，這種模式下UI變化後我們的的設計可能也需要跟着變。
而右邊是基于領域驅動開發，在開發前先去思考業務的本質，先把領域層分析出來，再根據分析出來的領域層進行界面設計、架構設計、代碼開發，這是由内而外的設計，這樣做出來的系統就會比較穩定。
業務模型
前面講的領域模型是基于靜态的關系，要了解業務其實更多的需要從動态的角度來了解業務運轉的過程，是以這時候就需要做業務模型。了解業務模型需要先了解以下幾個概念：
業務對象
業務主體主要有 業務執行者、業務勞工、業務實體。
要了解這三個對象，我們首先需要知道什麼是業務，業務是指一個組織可以向組織外的人提供服務。
業務執行者(Business Actor) ：組織外的人，來享受這個服務的人就稱為業務執行者；
業務勞工(Business worker) ：提供業務的 組織的内部支撐人員
業務實體(Business Entity) ：提供業務的 組織的内部資訊系統
了解這幾個概念還是有點拗口，我們來看看下面一張圖，一個餐廳對象的業務模組化
右邊大的黑框是提供業務的組織，是餐廳；圖的左邊是個業務執行者，是顧客；而在餐廳内部又分為業務勞工（領位員、點餐員、廚師等），業務實體（餐廳點餐管理系統）
我們在做業務模組化時需要注意，所有業務對象在圓圈的右下方需要有個斜線，這是一個模組化規範。
業務用例
概念：組織對外提供的業務服務
一個銀行是一個提供業務的組織，這就是業務用例，考察的對象是銀行這個組織而不是系統。
業務流程
業務用例是最基本的定義，而要分析業務動态的過程就需要業務流程，我們一般用時序圖來表示。
餐廳現狀的業務流程
這時候所有的動作步驟全部靠人參與
建設系統後的業務流程
有了系統後系統可以承擔一部分工作，有了系統能改善業務流程、提高價值、降低成本，這就是 建設系統的價值以及意義 ，否則就沒必要做系統建設了。
業務流程分析的作用
- 動态表達業務運轉的過程
- 隻有很好的了解了業務流程，才能設計出更好的支援該業務的系統
- 通過對比系統實施前後的流程變化，分析優化點，評估系統價值
小結
在準備做一個系統之前需要先分析業務，将業務了解清楚。了解業務既有靜态的了解（領域模型）又有動态的了解（業務流程），隻有将業務了解清楚才能做出良好的系統。
需求分析
需求分析是需求工程的環節，整個需求工程分為兩大塊
前期主要是做需求開發，包括需求調研、需求分析、需求定義；後期需要做需求管理，包括需求确認、需求跟蹤、需求變更控制。
咱們架構師主要聚焦在 需求分析 和 需求定義 兩個環節。
需求分析階段活動模型
需求分析階段是由系統分析師 基于業務分析師輸出的領域模型、業務模型 再結合 需求調研成果 輸出需求分析階段的成果，主要包括 系統上下文， 功能型需求（用例模型） 和 非功能性需求（性能等）。
系統上下文
系統上下文是指系統與周邊使用者和其它系統之間的關系
系統上下文的繪制很簡單，就是将準備開發的系統畫在中間，把使用者和對接的周邊系統畫出來這就叫系統上下文。
系統用例
系統用例是指系統被使用的案例，主要是從業務流程中推導出來，系統用例的命名規範主要是使用動詞短語，如：添加使用者、查詢話費等短語。
我們可以對系統用例細化，如上對登記入座資訊這一用例進行細化
系統用例與業務用例的差別與聯系
- 業務用例是描述組織對外提供的能力，系統用例是描述系統對外提供的能力，兩者考察的對象不一樣
- 系統用例是業務用例相應流程中對系統的一個操作
功能與用例的差別和聯系
- 用例是需求分析的産物，描述的是某種使用者使用系統完成什麼業務
- 功能是設計階段的産物，是根據系統用例和架構中的元件推導出來的
- 功能是靜态的，用例是動态的
- 從文法角度來說，用例是動詞短語，功能是名詞短語 例：用例命名（查詢空位），功能命名（空位查詢）
- 常見的錯誤：描述需求時拿出一份功能清單
非功能性需求
主要是确定一些非功能性需求，比如：可用性、 性能、 安全性、 經濟性、可擴充性、 可伸縮性、可移植性等等 可用性、性能、安全性是需要重點關注的内容，我們後期專門拿出來講。
架構設計（重點）
前面的業務分析與需求分析一般是由其他專人來做，那麼這一塊的内容則是架構師的工作，需要重點關注。
在系統簡單時我們需要從 功能角度 對系統進行分解和拆分，這個時候我們隻要做下概要設計和詳細設計就可以。
在複雜系統時我們需要從 元件角度 對系統進行分解和拆分，這個時候我們就需要做架構設計與概要設計。
元件、功能、子產品
元件是架構設計階段考慮的單元（程序級别），功能、子產品是概要設計、詳細設計考慮的單元；一個元件可包含多個子產品，涉及多個功能；一個功能的實作可能需要多個元件中的相應子產品來協作完成。
我們用一張圖來了解他們三者之間的關系
前後端分離的一個項目從程序角度劃分出三個元件，分别是web前端、後端接口服務、背景服務， 為了實作使用者查詢這個功能必須要在相應元件裡都需要有相應的子產品
一個元件裡可以有多個不同的子產品，各個元件裡的子產品互相協作完成某一個功能
架構
如果用一句話來描述什麼是架構，那應該可以這樣定義：架構是系統的内部結構（元件以及它們之間的關系）還要包含系統的技術要素。做架構設計其實就是幹這兩件事。
架構設計有兩個目标：
- 滿足功能性需求
- 滿足非功能性需求
架構設計階段活動模型
架構設計階段是由系統架構師 參照需求分析的産物（SRS），再通過對系統分析師、項目經理的咨詢輸出架構設計階段的成果，主要包括 架構工作計劃 、 邏輯架構、實體架構、開發元件一覽表、部署元件一覽表、技術選型一覽表
那如何來衡量一個架構的設計好壞呢？
在設計完成時我們可以通過設計資料的規範性以及設計思路、方案決策、技術選型的合理性來校驗；
在系統實作後可以通過功能性和非功能性需求的滿足程度來校驗。
邏輯架構設計（非技術型）
- 将系統從非技術角度分解成若幹邏輯元件，并建立它們之間的關系，以滿足系統需求。關系分靜态和動态，其中靜态關系用元件圖表示，動态關系用序 列圖表示。
- 邏輯架構中，元件名稱使用母語以便了解
- 邏輯架構不涉及技術元素，隻是純概念上的表述
- 邏輯架構的讀者可以是非技術人員
- 邏輯架構設計完成後應和系統分析師、産品經理等人員一起确認，檢查是否滿足需求
我們看一個典型的邏輯架構
實體架構設計（技術型）
- 将邏輯架構中的元件轉換為技術性的實體元件，名稱使用英文，在實作時應遵循這些命名
- 實體元件粒度有大有小，可表現為子系統、程序、對象等多種形式
- 實體架構還需要解決非功能性需求
- 實體架構還要和後續設計和實作進行銜接
- 非技術人員可能難以了解
我們看一個典型的實體架構
架構設計為系統的總體設計，決定了系統的元件劃分、關鍵技術方案決策、技術選型 架構設計上接需求，下接進一步的設計和實作，是決定系統實作的品質、效率、成本的關鍵階段
概要設計與詳細設計
概要設計
概要設計階段的主要内容是進行功能子產品劃分以及接口定義（接口名稱、功能概要、參數、傳回值）
概要設計階段活動模型
概要設計階段是由開發組長 基于系統用例、開發元件一覽表 再結合對架構師和系統分析師的咨詢輸出概要設計階段成果，主要包括 功能一覽表 ， 接口說明書。
詳細設計
詳細設計階段的主要内容是描述内部子產品實作、界面設計以及資料庫設計
詳細設計階段活動模型
詳細設計階段可能會根據工作内容進行分工，主要結合之前的産出輸出詳細設計階段的成果，主要包括 界面設計 ， 子產品内部設計 ， 資料庫設計。
後續工程階段
開發階段活動模型
開發階段主要是由開發人員結合架構設計的産物以及詳細設計的産物編寫相應代碼。
測試階段活動模型
測試階段主要是由測試人員結合架構設計的産物以及詳細設計的産物進行功能測試，包括功能性需求以及非功能性需求，需要對外輸出 測試計劃，測試用例 以及 測試報告。
部署階段活動模型
部署階段主要是由部署人員結合架構設計的産物以及跟開發人員的咨詢進行元件部署，這一階段需要輸出部署計劃、部署方案、部署手冊、部署腳本、部署實施 等
運維階段活動模型
運維階段主要是由運維人員結合架構設計的産物進行系統運維，需要輸出運維計劃、運維方案、運維手冊、運維腳本、運維報告 等。
以上，希望對你有所幫助！
End