1. 軟件架構設計的What & Why
● 啥是軟件架構（Software Architecture）？
軟件架構是指在一定的設計原則基礎上，從不同角度對組成系統的各部分進行搭配和安排，形成系統的多個結構而組成架構，它包括該系統的各個組件，組件的外部可見屬性及組件之間的相互關係。組件的外部可見屬性是指其他組件對該組件所做的假設。
軟件架構設計就是從宏觀上說明一套軟件系統的組成與特性。
軟件架構設計是一系列有層次的決策 ，比如：功能與展現的決策；技術架構的決策；自主研發還是合作；商業軟件還是開源軟件 。
● 爲啥要進行軟件架構設計？
業務需求層出不窮；軟件系統越來越複雜；參與的人越來越多；共性和特殊性的問題越來越多；技術發展日異月新；……
2. 軟件架構師
2.1. 軟件架構師是幹什麼的
| 介於需求與開發的中間人 | 良好的溝通能力 |
|---|---|
| 能夠統領全局的大牛 | 良好的大局觀 |
| 能夠將需求轉換爲技術 | 洞悉前沿與市場嗅覺 |
| 能夠爲軟件研發提供指導 | 見多識廣的大牛 |
| 需要全面思考軟件系統方方面面的問題 | 縝密地思考問題 |
| 能夠攻關和搞定重要技術難題 | 公司可信賴的支柱 |
2.2. 架構師的素質
| 全局思維 |
從業務、市場，到技術實現； 從軟件的過去、現在，到將來； 從外部客戶，到內部研發； 從軟件研發，到硬件部署； 從功能實現，到運行效率 |
| 戰略思維 |
在所在行業的發展戰略； 在業務領域的發展戰略； 在技術方向的發展戰略； 在潛在市場的發展戰略。 |
| 前瞻思維 |
市場趨勢的發展動向； 前沿技術的發展動向； 競爭對手的發展動向； 合作伙伴的發展動向。 |
| 抽象思維 |
各項業務需求：抽象成功能模塊； 各項功能的實現：抽象成軟件架構。 |
| 逆向思維 |
假如不實現會怎樣？ 假如沒搞定會怎樣？ 假如沒有它會怎樣？ 假如被延期會怎樣？ |
2.3. 架構師的分類
隨着行業和社會的發展，架構師的定義和分類越來越廣泛和細分，廣泛和細分其實並不矛盾，如果“廣泛”是x軸，“細分”是y軸，則二維座標系x和y軸中間的任一點就是一種架構師類別。但總體來說，或目前來說，集合業界的大致認知，總結如下：
| No. | 分類 | 描述 |
| 1 | 解決方案架構師 | 與客戶探討業務需求，將業務、市場，與技術、產品結合起來，爲客戶提供解決他們需求的方案。 |
| 2 | 系統架構師 | 也稱應用架構師。最終確認和評估系統需求，並將業務轉換爲技術，爲研發人員制訂核心框架與技術規範 爲研發工作澄清技術細節並掃清技術障礙 。 |
| 3 | 平臺架構師 | 這裏的平臺其實包括兩個平臺，一個是系統平臺，也就是負責搭建多個系統整合的系統應用平臺；另外一個其實是基礎平臺，是專門負責搭建基礎技術平臺；兩者其 實區別蠻大，也經常容易被從業人員混亂。舉個簡單例子，金蝶有平臺架構師一職，但是金蝶BOSS應用和金蝶中間件兩者招聘的對象和技術要求是截然不同的。 |
| 4 | 業務架構師 | 業務架構其實已經開始脫離技術層面了，但是它要求架構師有跨越多系統的大局觀，去整合和組織不同系統的技術平臺與交互模式。其實這個職位的未來也就是CIO了。 |
| 5 | 網絡架構師 | 過去，我們可能聽的最多的是網絡工程師。不錯，一個優秀的網絡架構師必須有足夠的網絡技術基底，並且它的關注點也是系統的基礎架構。比如說如果搭建並優化集羣環境，如果構建基於雲計算的系統應用與部署等等。它對於像淘寶、騰訊這樣的互聯網公司是極其重要的。 |
| 6 | 移動架構師 | 移動互聯網的迅猛發展橫向和縱向都細分出了很多新的職責和崗位，移動架構師的職責和作用日益重要，既要整體和全局考慮整個前後端的軟件系統架構，又要重點深入移動客戶端的架構設計的方方面面，既要有跨平臺思維，又要拿捏好原生和混合開發的尺度，另外移動應用的特點，導致移動架構師必須要比傳統系統架構師更加註重非功能性的質量屬性。 |
| 7 | 前端架構師 | 這也是移動互聯網的迅猛發展而細分出來的新的職責和崗位，這裏的前端特指網站開發中的前端，主要考慮前端呈現層的設計（HTML/CSS/JS/AJAX/RIA/…），跨瀏覽器設計等等。 |
| 8 | ... | ... |
3. 軟件需求
軟件架構設計中常說需求驅動架構設計，可見需求在整個架構設計中起到了關鍵指引和方向的作用，如果以目標導向爲原則，則需求的滿足和實現就是架構設計的終極目標。
OK，在進行架構設計之前，我們先看下軟件需求。
3.1. 軟件需求怎麼來的（軟件需求的過程）
| 階段 |
需求階段 |
說明 |
什麼人做什麼事 |
可能產生的文檔 |
||
| 客戶方 |
實施方 |
客戶方 |
實施方 |
|||
| 1 |
業務需求 |
來自客戶的原始需求，背景描述，業務訴求和期望目標。 |
項目負責人或接口人描述需求或提供客戶方需求文檔。 |
銷售或售前接觸客戶，聽取和記錄需求。 |
工作說明書（SOW），或邀標書 |
售前的方案建議書 |
| 2 |
用戶需求 |
通常是在問題定義的基礎上進行用戶訪談、調查，對用戶使用的場景進行整理，從而建立從用戶角度的需求。 |
項目負責人或接口人接受訪談和調研。 |
需求分析師或項目經理等進行需求調研。 |
|
調研計劃、用戶需求調研提問庫、調研日誌、用戶需求說明書 |
| 3 |
軟件需求 |
從系統實現的角度描述的需求。開發人員（設計和分析人員）在業務需求、用戶需求的基礎上形成的。 |
|
需求分析師或項目經理、架構師等討論和細化需求，編寫需求文檔 |
|
SRS（Software Requirement Specification）軟件需求規格說明書 |
3.2. 軟件需求的分類：
另外，也有McCall軟件質量模型：
注：在架構設計中，對非功能性需求的重視程度，也會影響架構設計的好與劣；但也要平衡過渡設計和適可而止的關係。
4. 軟件架構的過程
業界軟件架構設計的方法論很多，各有各自的應用場景和特點，下文結合ADMEMS（Architecture Design Method has been Extended to Method System）架構設計方法論說明軟件架構的過程：
| 架構階段 |
目標 |
方式方法 |
現實工作場景 |
| 預架構階段 |
全面理解需求；需求結構化，摒棄“需求列表”，建立二維需求觀（ADMEMS矩陣）。 |
使用ADMEMS矩陣方法，捋清需求間關係和發現衍生需求。 |
1、與人：與項目經理、需求分析師等內部需求人員瞭解需求；與客戶瞭解需求（不建議架構師做需求分析師角色）。 |
| 概念架構 |
高層組件及其關係 |
1、初步設計，基於關鍵功能，藉助魯棒圖進行以發現職責爲目的的初步設計（不是必須）。 |
1、參與內部討論：項目可行性分析、討論，從需求、技術、人力、風險等角度提供建議。 |
| 細化架構 |
|
5視圖法 |
在項目概要設計階段，進行架構設計，制定規範和約定，爲詳細設計提供指導。 |
| 實現 |
詳細設計 |
架構設計形成詳細設計文檔 |
在項目實現階段，對開發人員提供規範指引和技術支持。 |
注：架構設計的過程和內容的不是固定不變的，現實中，比如售前提供解決方案中，很多時候需要架構師提供細化架構中才會深思的邏輯架構、物理架構等，這時候，架構師就需要有螺旋思維和跳躍思維的方式，就像武功中，招式是死的，人是活的，要學會靈活運用。
5. 軟件架構設計的方式方法
5.1. 多視圖法
多視圖方法是業界廣泛認同的一種架構設計思路，包括：
● SEI的3視圖法：
模塊視圖、組件-連接器視圖、分配視圖。
● 西門子的4視圖法：
概念視圖、模塊視圖、代碼視圖、執行視圖。
● RUP的4+1視圖法：
用例視圖、邏輯視圖、開發視圖、進程視圖、物理視圖。
● 聯邦企業架構框架：
技術架構視圖、信息架構視圖、應用架構視圖、業務架構視圖。
● ……
5.2. 5視圖法
5視圖法分析的意義：
● 全面分析軟件系統方方面面的問題
● 儘早地發現和排除項目風險與不確定因素
● 從不同角度去展現要設計的軟件系統
● 爲項目進行中不同的干係人提供指導：
-- 邏輯架構描述系統功能，並指導系統測試
-- 開發架構規範軟件的層次及代碼風格
-- 數據架構指導數據庫的設計
-- 運行架構定義了一些關鍵過程的設計
-- 物理架構明確軟件如何部署與實施
5.3. 5視圖法設計步驟
兩種觀念：
| 觀念 |
設計步驟 |
| 觀念一 |
順序進行： 1、邏輯架構。 2、開發架構 3、數據架構 4、運行架構 5、物理架構 |
| 觀念二 |
5個視圖是穿插進行設計的，對複雜系統而言，根本不可能將邏輯視圖設計完了後再考慮其它視圖。 |
| 筆者觀念 |
觀念一和觀念二的情況在現實狀況中都可能存在，要根據具體情況具體分析，但總體而言，5視圖穿插進行思考更有利於思考的全局性和完整性。 |
5.4. 如何進行5視圖法的設計
以下5視圖表格中的工具和方法每個架構師或略有差異，以下僅爲參考。
5.4.1. 邏輯架構
邏輯架構的重點是考慮軟件功能性需求。
| No. |
考慮的方面 |
產出物 |
工具 |
說明 |
| 1 |
系統功能劃分爲幾個子系統與功能模塊？ |
系統功能樹 |
樹型結構圖 |
|
| 2 |
向什麼用戶提供什麼樣的功能？ |
用例模型 |
UML用例圖 |
體現用戶和行爲 |
| 3 |
每個功能都是怎樣的操作流程與分支？ |
用例描述 |
用例描述表
|
含輸入輸出、事件流分析； 不要有界面描述 |
| UML活動圖 |
進行業務流程分析，包括泳道圖 |
|||
| 4 |
如何通過界面與用戶交互？怎樣交互？ |
魯棒分析 |
魯棒圖 |
通過對“用例描述表”進行原文分析法揀出名詞和動詞 |
| 5 |
應當設計哪些類與界面？怎樣設計？ |
領域模型 |
UML類圖 |
|
| 6 |
與哪些外部系統接口？怎樣接口？ |
接口描述 |
UML類圖 |
|
5.4.2. 開發架構
開發架構重點關注的是開發編碼實現方面的問題。
| No. |
考慮的方面 |
產出物 |
工具 |
說明 |
| 1 |
分層結構設計 |
分層架構圖（開發架構圖） |
各種繪圖工具 |
好的分層結構支持自動化測試 |
| 2 |
開發技術選項 |
開發語言 開發框架 開發工具 |
|
考慮商用產品、開源框架、自研框架 |
| 3 |
模塊劃分 |
源碼工程；Project目錄結構； 分包(分庫) |
|
|
| 4 |
開發規範 |
開發/編碼規範文檔； |
|
|
| 5 |
軟件質量屬性 |
分析和決策結果 |
|
考慮運行期和開發期軟件質量屬性，並權衡利弊進行決策。 |
5.4.3. 數據架構
數據架構不僅僅要考慮開發中涉及到的數據庫，實體模型，也要考慮物理架構中數據存儲的設計。
| No. |
考慮的方面 |
產出物 |
工具 |
說明 |
| 1 |
數據是集中還是分佈存儲的？如何考慮分佈式存儲？ |
數據架構圖 |
|
|
| 2 |
領域模型到數據庫表的轉換？表結構關係的設計？ |
邏輯模型 物理模型 ER圖 |
Power Designer Visio |
|
| 3 |
實體如何設計？充血模型和貧血模型？ |
UML類圖 |
|
|
| 4 |
使用什麼數據庫？關係型還是非關係型？ |
選型結果 |
|
|
| 關係型數據庫 |
非關係型數據庫（NoSQL） |
| Oracle（首次發行：1980年） MySQL（首次發行：1995） MS SQL Server（首次發行：1989） PostgreSQL（首次發行：1989） IBM DB2（首次發行：1983） Microsoft Access（首次發行：1992） Sybase ASE（首次發行：1987） SQLite（首次發行：2000） …… |
MongoDB（首次發行：2009） Cassandra（首次發行：2008） Apache CouchDB Hbase Redis db4o BaseX …… |
5.4.4. 運行架構
運行架構關注的不再是全局而是局部，着重關注那些關鍵點與難點，常常需要技術攻關與預研。主要考慮控制流、通訊機制、資源爭用、鎖機制、同步異步、併發、串行，同時也要考慮質量屬性。
| No. |
考慮的方面 |
產出物 |
工具 |
說明 |
| 1 |
運行：同步vs.異步；併發vs.串行 |
考慮開發架構中代碼的實現。 |
|
|
| 2 |
交互：對象間交互；狀態轉換 |
考慮開發架構的合理性，到類、到接口、到代碼。 |
|
|
| 3 |
質量：安全；可靠；可伸縮 |
考慮開發架構的合理性 |
|
|
| 4 |
性能：響應時間；吞吐量 |
估算： 在線人數、併發人數； 每秒事務量； 響應時間。 |
|
|
5.4.5. 物理架構
物理架構主要考慮硬件選擇和拓撲結構，軟件到硬件的映射，軟硬件的相互影響。
|
|
考慮的方面 |
產出物 |
工具 |
說明 |
| 1 |
網絡方面：網絡拓撲；網絡設備；安全機制 |
拓撲圖 安全規範 |
|
|
| 2 |
性能方面：可靠性、可伸縮性 |
需要什麼樣設備性能 |
|
|
| 3 |
部署方面：集中式還是分佈式；組件部署 |
部署圖
|
|
|
6. 一個思考，誰驅動了架構設計？
需求驅動了架構設計？
質量屬性了驅動了架構設計（ADD）？
領域驅動了架構設計（DDD）？
風險驅動了架構設計？
質疑驅動了架構設計？
……
到底是誰驅動了架構設計？我們以船舶設計建造爲例，來看這些問題：
| 目標和結果 à |
問題 à |
回答 à |
小結 |
| 設計和製造一艘遠洋貨輪，能經歷數月海上顛簸和長途跋涉，並保證貨物的安全和完整，最後能順利抵達目標港口。 |
我們爲什麼要設計和製造這樣的大船？ |
市場有這個需求； 獲利很豐厚； 解決就業； …… |
不管是外部需求還是內部的需求，都是需求。不正是需求驅動嗎？ |
| 如何保證貨船能長途航行並經受波濤和風雨？ |
船要造的結實； |
魯棒性 |
這些不正是質量屬性驅動設計嗎？ |
| 引擎設計的強勁； |
性能 |
||
| 船的燃料充足； |
持續可用性 |
||
| 裝備衛星電話、GPS、雷達等設備 |
互操作性 |
||
| 貨物和人員要安全 |
安全性 |
||
| 船舶設計師怎麼設計這樣的船舶？ |
現在都會通過計算機進行船舶的CAD和3D模型設計。 |
是不是佷似領域模型驅動了設計？ |
|
| 造船一定有很多風險吧？ |
那是，比如訂貨方客戶有時提出改裝船舶的意見（需求變化的風險）；有時某些工藝成品率不穩定（質量風險）；等等。 |
所有可能的風險點在設計時都要考慮到，做好預案，才能保證架構設計的可行性和靈活性，風險驅動了架構設計。 |
|
| 上面怎麼提了那麼多問題，其實還有很多問題，比如…… |
嗯，你現在有不少疑問了。 |
不斷的質疑架構設計中可能存在各種問題，有質疑纔有思考，纔有解決方案，從而推動架構設計的不斷完善。 |
總結：
以上幾個方面都能驅動架構設計，並不是零和的規則，而是一個立方體從不同方向看的問題。以上方面有些是指導思想，有些是行動方式，有的兼而有之，闡述方式看似不同，終極目標還是造出大船（實現需求），造出好船（質量屬性），怎麼造（領域模型），造的順利（風險控制），挑不出毛病（架構師自己先質疑問題並解決了）。
7. 軟件架構設計的誤區
● 高開高走落不到實處
● 理想與現實需要折中
● 遺漏關鍵性約束與非功能需求
● 爲虛無的未來埋單而過度設計
● 過早做出關鍵性決策
● 客戶說啥就是啥成爲醬油哥
● 埋頭幹活兒缺乏前瞻性
● 架構設計還要考慮系統可測性
● 架構設計不要企圖一步到位
8. 部分參考資料
溫昱的《一線架構師實踐指南》