（一）、概念解析

1.什么是方法論？

我們拿到一個輸入，然后根據(jù)這個輸入預期一個輸出，把中間這個過程描述出來就是方法論。所以我們本篇講的架構師方法論就是架構師先拿到經(jīng)過需求分析出來的輸入，然后完成架構設計，這個過程就是架構設計方法論。

2.什么是設計？

設計是實現(xiàn)意圖的書面表現(xiàn)形式，而非口頭的東西；設計是要讓實現(xiàn)者能理解設計者的意圖，是給別人看而非自己看；設計是要讓不同的實現(xiàn)者做出來的東西差不多；設計是嚴肅的，后續(xù)實現(xiàn)者不能隨意偏離設計。

3.什么是系統(tǒng)架構師

作為系統(tǒng)架構師你需要跳出代碼層面的設計，站在更加宏觀的角度進行把握。

你關注的是整個系統(tǒng)而不是其中的一兩個查詢模塊，你看到的元素更多的是 ：人 、硬件 、軟件 、網(wǎng)絡。

（二）、業(yè)務分析

1.業(yè)務分析概述

業(yè)務分析是在系統(tǒng)開發(fā)之前對系統(tǒng)要解決的業(yè)務領域的研究過程，目的是搞清楚該業(yè)務領域的概念以及業(yè)務的運轉過程開發(fā)系統(tǒng)的目的一般是為了優(yōu)化業(yè)務流程，使業(yè)務運轉得更加高效、經(jīng)濟系統(tǒng)的價值主要在于實施后能夠幫助客戶帶來多少業(yè)務價值不管有無系統(tǒng)，業(yè)務通常是不變的

2.業(yè)務分析階段活動模型

業(yè)務分析階段是由業(yè)務分析師 基于自身的業(yè)務知識和類似產(chǎn)品的參考，再結合客戶、領域專家的咨詢和指導輸出業(yè)務分析階段的成果，主要包括   領域模型 和 業(yè)務模型。

領域模型

領域模型是對領域內的概念類或現(xiàn)實世界中對象的可視化表示。又稱概念模型、領域對象模型、分析對象模型。它專注于分析問題領域本 身，發(fā)掘重要的業(yè)務領域概念，并建立業(yè)務領域概念之間的關系。概念比較深奧，其實說白了就是我們把基于對業(yè)務的理解畫成一個類圖，并畫出這些類之間的關系（面向對象），下面我們看一個實際的領域模型然后加深一下理解。

在領域模型繪制時經(jīng)常會出現(xiàn)下面兩種典型錯誤：

（1）將待開發(fā)系統(tǒng)也放在領域模型里面：待開發(fā)系統(tǒng)要不要出現(xiàn)在領域模型中取決于你的業(yè)務離開待開發(fā)的系統(tǒng)能不能玩的轉。舉個例子：如果開發(fā)的是共享單車的信息系統(tǒng)，共享單車離開信息系統(tǒng)肯定玩不轉，所以這時候信息系統(tǒng)需要出現(xiàn)在領域模型。

（2）概念劃分不清，關系沒有畫到位：比如屬性畫成了類，繼承關系搞錯

領域模型的作用：

領域模型可以整理業(yè)務中的概念以及關系，幫助團隊中的成員對業(yè)務的理解保持一致；往后可以指導數(shù)據(jù)庫設計、系統(tǒng)功能設計、指導開發(fā)。

現(xiàn)在有種開發(fā)模式是基于UI指導開發(fā)，根據(jù)UI進行數(shù)據(jù)庫數(shù)據(jù)庫設計、代碼編寫，我們稱之為 “急功近利式” 開發(fā)模式。因為UI是系統(tǒng)表面性的東西，是異變的，不穩(wěn)定的，這種模式下UI變化后我們的的設計可能也需要跟著變。而右邊是基于領域驅動開發(fā)，在開發(fā)前先去思考業(yè)務的本質，先把領域層分析出來，再根據(jù)分析出來的領域層進行界面設計、架構設計、代碼開發(fā)，這是由內而外的設計，這樣做出來的系統(tǒng)就會比較穩(wěn)定。

業(yè)務模型

前面講的領域模型是基于靜態(tài)的關系，要理解業(yè)務其實更多的需要從動態(tài)的角度來了解業(yè)務運轉的過程，所以這時候就需要做業(yè)務模型。理解業(yè)務模型需要先理解以下幾個概念：

（1）業(yè)務對象

業(yè)務主體主要有 業(yè)務執(zhí)行者、業(yè)務工人、業(yè)務實體。

要理解這三個對象，我們首先需要知道什么是業(yè)務，業(yè)務是指一個組織可以向組織外的人提供服務。業(yè)務執(zhí)行者(Business Actor) ：組織外的人，來享受這個服務的人就稱為業(yè)務執(zhí)行者；業(yè)務工人(Business worker) ：提供業(yè)務的 組織的內部支撐人員業(yè)務實體(Business Entity) ：提供業(yè)務的 組織的內部信息系統(tǒng)理解這幾個概念還是有點拗口，我們來看看下面一張圖，一個餐廳對象的業(yè)務建模

右邊大的黑框是提供業(yè)務的組織，是餐廳；圖的左邊是個業(yè)務執(zhí)行者，是顧客；而在餐廳內部又分為業(yè)務工人（領位員、點餐員、廚師等），業(yè)務實體（餐廳點餐管理系統(tǒng)）

我們在做業(yè)務建模時需要注意，所有業(yè)務對象在圓圈的右下方需要有個斜線，這是一個建模規(guī)范。

（2）業(yè)務用例

概念：組織對外提供的業(yè)務服務

一個銀行是一個提供業(yè)務的組織，這就是業(yè)務用例，考察的對象是銀行這個組織而不是系統(tǒng)。

（3）業(yè)務流程

業(yè)務用例是最基本的定義，而要分析業(yè)務動態(tài)的過程就需要業(yè)務流程，我們一般用時序圖來表示。

餐廳現(xiàn)狀的業(yè)務流程

這時候所有的動作步驟全部靠人參與

建設系統(tǒng)后的業(yè)務流程

有了系統(tǒng)后系統(tǒng)可以承擔一部分工作，有了系統(tǒng)能改善業(yè)務流程、提高價值、降低成本，這就是 建設系統(tǒng)的價值以及意義 ，否則就沒必要做系統(tǒng)建設了。

（4）業(yè)務流程分析的作用

動態(tài)表達業(yè)務運轉的過程只有很好的理解了業(yè)務流程，才能設計出更好的支持該業(yè)務的系統(tǒng)通過對比系統(tǒng)實施前后的流程變化，分析優(yōu)化點，評估系統(tǒng)價值

小結：在準備做一個系統(tǒng)之前需要先分析業(yè)務，將業(yè)務理解清楚。理解業(yè)務既有靜態(tài)的理解（領域模型）又有動態(tài)的理解（業(yè)務流程），只有將業(yè)務理解清楚才能做出良好的系統(tǒng)。

（三）、需求分析

需求分析是需求工程的環(huán)節(jié)，整個需求工程分為兩大塊

前期主要是做需求開發(fā)，包括需求調研、需求分析、需求定義；后期需要做需求管理，包括需求確認、需求跟蹤、需求變更控制。

咱們架構師主要聚焦在 需求分析 和 需求定義 兩個環(huán)節(jié)。

需求分析階段活動模型

需求分析階段是由系統(tǒng)分析師 基于業(yè)務分析師輸出的領域模型、業(yè)務模型 再結合 需求調研成果 輸出需求分析階段的成果，主要包括   系統(tǒng)上下文， 功能型需求（用例模型） 和 非功能性需求（性能等）。

（1）系統(tǒng)上下文

系統(tǒng)上下文是指系統(tǒng)與周邊用戶和其它系統(tǒng)之間的關系

系統(tǒng)上下文的繪制很簡單，就是將準備開發(fā)的系統(tǒng)畫在中間，把用戶和對接的周邊系統(tǒng)畫出來這就叫系統(tǒng)上下文。

（2）系統(tǒng)用例

系統(tǒng)用例是指系統(tǒng)被使用的案例，主要是從業(yè)務流程中推導出來，系統(tǒng)用例的命名規(guī)范主要是使用動詞短語，如：添加用戶、查詢話費等短語。

我們可以對系統(tǒng)用例細化，如上對登記入座信息這一用例進行細化

a.系統(tǒng)用例與業(yè)務用例的區(qū)別與聯(lián)系

業(yè)務用例是描述組織對外提供的能力，系統(tǒng)用例是描述系統(tǒng)對外提供的能力，兩者考察的對象不一樣系統(tǒng)用例是業(yè)務用例相應流程中對系統(tǒng)的一個操作。

b.功能與用例的區(qū)別和聯(lián)系

用例是需求分析的產(chǎn)物，描述的是某種用戶使用系統(tǒng)完成什么業(yè)務

功能是設計階段的產(chǎn)物，是根據(jù)系統(tǒng)用例和架構中的組件推導出來的

功能是靜態(tài)的，用例是動態(tài)的

從語法角度來說，用例是動詞短語，功能是名詞短語 例：用例命名（查詢空位），功能命名（空位查詢）

常見的錯誤：描述需求時拿出一份功能清單

（3）非功能性需求

主要是確定一些非功能性需求，比如：可用性、 性能、 安全性、 經(jīng)濟性、可擴展性、 可伸縮性、可移植性等等 可用性、性能、安全性是需要重點關注的內容，我們后期專門拿出來講。

（四）、架構設計（重點）

前面的業(yè)務分析與需求分析一般是由其他專人來做，那么這一塊的內容則是架構師的工作，需要重點關注。在系統(tǒng)簡單時我們需要從 功能角度 對系統(tǒng)進行分解和拆分，這個時候我們只要做下概要設計和詳細設計就可以。在復雜系統(tǒng)時我們需要從 組件角度 對系統(tǒng)進行分解和拆分，這個時候我們就需要做架構設計與概要設計。

組件、功能、模塊

組件是架構設計階段考慮的單元（進程級別），功能、模塊是概要設計、詳細設計考慮的單元；一個組件可包含多個模塊，涉及多個功能；一個功能的實現(xiàn)可能需要多個組件中的相應模塊來協(xié)作完成。

我們用一張圖來理解他們三者之間的關系 

前后端分離的一個項目從進程角度劃分出三個組件，分別是web前端、后端接口服務、后臺服務， 為了實現(xiàn)用戶查詢這個功能必須要在相應組件里都需要有相應的模塊。一個組件里可以有多個不同的模塊，各個組件里的模塊相互協(xié)作完成某一個功能

架構

如果用一句話來描述什么是架構，那應該可以這樣定義：架構是系統(tǒng)的內部結構（組件以及它們之間的關系）還要包含系統(tǒng)的技術要素。做架構設計其實就是干這兩件事。

架構設計有兩個目標：

滿足功能性需求和滿足非功能性需求

架構設計階段活動模型

架構設計階段是由系統(tǒng)架構師 參照需求分析的產(chǎn)物（SRS），再通過對系統(tǒng)分析師、項目經(jīng)理的咨詢輸出架構設計階段的成果，主要包括   架構工作計劃 、 邏輯架構、物理架構、開發(fā)組件一覽表、部署組件一覽表、技術選型一覽表。

那如何來衡量一個架構的設計好壞呢？

在設計完成時我們可以通過設計資料的規(guī)范性以及設計思路、方案決策、技術選型的合理性來校驗；在系統(tǒng)實現(xiàn)后可以通過功能性和非功能性需求的滿足程度來校驗。

1.邏輯架構設計（非技術型）

將系統(tǒng)從非技術角度分解成若干邏輯組件，并建立它們之間的關系，以滿足系統(tǒng)需求。關系分靜態(tài)和動態(tài)，其中靜態(tài)關系用組件圖表示，動態(tài)關系用序 列圖表示。邏輯架構中，組件名稱使用母語以便理解邏輯架構不涉及技術元素，只是純概念上的表述邏輯架構的讀者可以是非技術人員邏輯架構設計完成后應和系統(tǒng)分析師、產(chǎn)品經(jīng)理等人員一起確認，檢查是否滿足需求。

我們看一個典型的邏輯架構

2.物理架構設計（技術型）

將邏輯架構中的組件轉換為技術性的物理組件，名稱使用英文，在實現(xiàn)時應遵循這些命名；物理組件粒度有大有小，可表現(xiàn)為子系統(tǒng)、進程、對象等多種形式；物理架構還需要解決非功能性需求物理架構還要和后續(xù)設計和實現(xiàn)進行銜接；非技術人員可能難以理解

我們看一個典型的物理架構

小結：架構設計為系統(tǒng)的總體設計，決定了系統(tǒng)的組件劃分、關鍵技術方案決策、技術選型 架構設計上接需求，下接進一步的設計和實現(xiàn)，是決定系統(tǒng)實現(xiàn)的質量、效率、成本的關鍵階段

（五）、概要設計與詳細設計

1.概要設計

概要設計階段的主要內容是進行功能模塊劃分以及接口定義（接口名稱、功能概要、參數(shù)、返回值）

概要設計階段活動模型

概要設計階段是由開發(fā)組長 基于系統(tǒng)用例、開發(fā)組件一覽表 再結合對架構師和系統(tǒng)分析師的咨詢輸出概要設計階段成果，主要包括  功能一覽表 ， 接口說明書。

2.詳細設計

詳細設計階段的主要內容是描述內部模塊實現(xiàn)、界面設計以及數(shù)據(jù)庫設計

詳細設計階段活動模型

詳細設計階段可能會根據(jù)工作內容進行分工，主要結合之前的產(chǎn)出輸出詳細設計階段的成果，主要包括  界面設計 ， 模塊內部設計 ， 數(shù)據(jù)庫設計。

（六）、后續(xù)工程階段

1.開發(fā)階段活動模型

開發(fā)階段主要是由開發(fā)人員結合架構設計的產(chǎn)物以及詳細設計的產(chǎn)物編寫相應代碼。

2.測試階段活動模型

測試階段主要是由測試人員結合架構設計的產(chǎn)物以及詳細設計的產(chǎn)物進行功能測試，包括功能性需求以及非功能性需求，需要對外輸出 測試計劃，測試用例 以及 測試報告。

3.部署階段活動模型

部署階段主要是由部署人員結合架構設計的產(chǎn)物以及跟開發(fā)人員的咨詢進行組件部署，這一階段需要輸出部署計劃、部署方案、部署手冊、部署腳本、部署實施 等

4.運維階段活動模型

運維階段主要是由運維人員結合架構設計的產(chǎn)物進行系統(tǒng)運維，需要輸出運維計劃、運維方案、運維手冊、運維腳本、運維報告 等。