什麼是架構設計

鑒於前幾篇文章被我親愛的老婆大人批判為「冗長無趣」，這次改過自新，力求極簡，有趣一點，萬一弄巧成拙，還請諸君見諒。

一、系統架構的概念

由愛德華·克勞利（Edward Crawley）、布魯斯·卡梅隆（Bruce Cameron）、丹尼爾·塞爾瓦（Daniel

也就是說，功能要1+1>2，這叫「湧現」。舉例說，一堆磚瓦木頭不能遮風擋雨，但它們可以組成一個溫暖的房子，房子的功能大於這一堆材料的功能之和，所以房子是一個系統。

知道了什麼是系統，再來看看系統架構要幹什麼：

1）確定系統的形式與功能。說白了就是分析需求。

2）確定系統中的實體、實體的形式與功能。就是對系統進行劃分。要完成這個任務，書中提出一些注意之點，就是要找出潛在實體，關注重要實體，完成實體抽象，定義系統邊界和系統所處的環境。

3）確定實體之間的關係。包括確定內部實體以及位於邊界處的實體間的關係，定義這些關係的形式與功能。也就是要定義內、外部介面。

4）預測湧現。預測最終功能實現、性能實現，還要預測系統故障，也就是非期望的湧現。

書中還從另一個角度，即對架構師職能做出說明：

1）消除歧義。也就是架構設計完了就不要再對需求有模糊曖昧的理解了。

2）定義系統概念。提出總體解決思路，定義系統中的關鍵名詞，定義關鍵衡量標準。

3）設計分解。把系統分解成實體以及實體間關係，這裡有個關鍵是控制系統複雜度，不要使規模過分膨脹。

可見，系統架構是一個介於需求與實現中間的步驟，既要分析需求，又要可以提出可行的實現方案。

系統架構適合一個人或少數人組成的團隊來完成，因為人多會導致思維的整體性不足。如果多人合作，最好的形式也是劃分層級，一個單元的一個層級要由一個人獨立來完成。這對架構師的知識面、綜合、分析、想像能力提出了比較高的要求。

二、軟體架構設計的輸入

在軟體行業的實踐中，上述系統架構設計任務第1點「確定系統的形式與功能」，是由產品設計部門在技術部門的支持下完成的。理想情況下，產品設計應交付如下文檔：

1）功能模型。推薦表達方式：用例圖+功能性能描述。

2）對象模型。推薦表達方式：產品級內外部對象圖。

3）動態模型。推薦表達方式：產品級業務流程的時序圖。

4）界面原型。推薦表達方式：低保真原型圖+注釋說明。

（這裡先列一點提綱，需求分析的內容後面可以專題探討。）

但世事往往如此：

我們想的是這樣的：

實際拿到的是這樣的：

三、軟體架構設計的輸出

軟體架構設計輸出一份或多份文檔，其內容框架如下：

1）方案概述。對設計方案的概括性描述。

2）設計約束。包括要遵循的標準或規範，技術上依賴的假設條件等。

3）技術選型。包括系統運行的軟硬體環境，研發、測試的軟硬體環境，編程語言，現有或開源框架、平台、模塊、基礎庫的重用策略。

4）系統結構。包括系統的網路部署結構，子系統劃分。推薦用UML部署圖、包圖描述。

5）關鍵技術設計。每個系統關鍵點不一樣，但一般都會有安全設計，一些演算法的設計。

6）介面設計。包括協議棧，子系統間的介面數據結構，子系統間的業務流程描述。業務流程推薦用UML序列圖描述。

7）數據設計。流動的數據已通過介面設計，這裡描述要存儲的數據。數據的組織形式不一樣，比如NoSQL，NewSQL，SQL等不同類型，描述方式也會不一樣。關係資料庫推薦用ER模型描述頂層邏輯結構，欄位表描述物理結構。

8）質量預測。對遺留缺陷率、平均無故障運行時間等質量指標進行預測，提出可能出現的缺陷和問題。

需要特別指出，一個系統的架構設計並不是一次性工作，它是一種持續迭代的輸出，所以架構要做一些長期考慮，保持一定的開放性，為後續擴展和修改保留可能性。

四、軟體架構師的日常

作為一個軟體架構師，日常工作會是什麼樣的呢？

1）開會和溝通。架構師要參與立項決策，主要是在系統技術可行性，質量、工期、成本預測上提供決策依據；參加產品設計講解會議；做方案預定階段的溝通、方案形成後的講解、方案實施階段的跟進和答疑。所有這些都是溝通工作。

2）構思和預研。架構師要構思架構，如果有不明確的技術點，需要查閱資料，甚至做一些突破和開創性的研究。

3）寫文檔。書面輸出架構設計文檔。

所以，架構師的工作看起來就是：聽聽聽，說說說，查查查，想想想，寫寫寫。（嗯，大體上所有的工作都是這樣。）

下期預告：

本期說的是架構設計要幹什麼，架構師要幹什麼，那麼這些工作，對架構師提出了什麼挑戰？架構師需要什麼樣的知識、能力和素質？下期我們探討這個問題，敬請關注。