任何軟件產品或項目前期都少不了：需求收集整理、業務規劃過程，後續實施，研發過程不管採取瀑布模式還是敏捷模式，在這兩者中間還是少不了軟件系統架構規劃設計過程，只是架構設計顆粒度和目標要求不同而已，可作爲後續回溯和研發總體方向。
基於以往項目產品實施經驗和參考其他相關係統架構理論書籍等，本文對軟件系統架構的總體認識理解，同時整理做系統架構設計時應遵循模式的相關理論知識，希望能給初級架構師、系統分析師、產品經理、項目經理、研發經理、研發工程師等有所參考。
關於架構
01 何爲系統架構
雖然命題爲軟件系統架構，但軟件基本上服務各個領域，軟件系統架構與現實生活中各業務領域的架構本質是一脈相承的。
每個領域都有其相關的特性，運作當中就存在不同的需求。爲了滿足不同的需求，各領域會針對不同需求不斷髮展出不同的解決方法、手段或工具等。
而在需求提出到實現（涉及方法、工具、手段等）之間，存在一個對業務需求、業務結構、行爲邏輯、屬性、關係等理解及分析的過程，系統性總結出來針對該過程的抽象化描述定義就是系統架構。
舉個例子，下面就我們所熟悉的行業領域來了解的架構是什麼。
電影行業的系統架構過程，如下圖：
從上面業務領域的系統架構（粗顆粒度）過程例子，我們可以看出架構有如下主要特性：
- 架構是基於需求的，在一定範圍內，具有抽象性、時效性、針對性；
- 需求是有顆粒度的，所以架構需要根據需求的顆粒度來設計；
- 需求是多方面的，需特別關注風險和約束，所以架構必須體現風險、約束條件等；
- 架構包含了衆多關聯羣體和他們所關注的事情，因此架構要體現多維度的視角。
02 設計的前提條件
在開始進行系統架構分析設計時，有幾點是需要遵守的：
- 只針對某一領域、某一時段內存在的業務需求，服務於某特定領域業務範圍需求，不可本末倒置；
- 系統架構設計是需求驅動的，是會隨着需求變化而變化的，首要條件必須要瞭解需求；
- 系統架構只是一個系統性的抽象化描述定義；
- 系統架構是需要充分考慮約束條件、風險的；
- 系統架構爲所有涉衆的人提供一個共同的遠景目標，但架構不包括每個部分的細節。
03 軟件系統架構定義
國外相關書籍關於軟件系統架構的一種定義如下：
軟件架構爲探索如何以最佳方式劃分一個系統、如何標識組件、組件之間如何通信、信息如何溝通、組成系統的元素如何能夠獨立地進化，以及上述的所有東西如何能夠使用形式化的和非形式化的符號加以描述。
簡化理解來說：
軟件系統架構可以說是爲軟件系統提供一個結構、行爲和屬性的高級抽象過程。
04 軟件系統架構價值
軟件的系統架構設計體現的價值如下：
- 保持系統完整和質量，系統的結構在需求變更中保持彈性。
- 控制複雜度，架構是一個不同問題和關注點的分解過程。
- 可複用，架構通過協助行爲定義了邊界，從而使各種粒度可以重用。
- 可預見/測試，系統結構、行爲、屬性在開始就定義了系統的原型。
- 改善項目溝通和管理，不同視圖支撐不同涉衆的關注點（例如組件或者子系統的並行開發）。
架構追求系統的長期效益，沒有架構的系統是代價高昂的，架構優劣可以用“需求變更成本”衡量。
軟件系統架構認識誤區
現實中，軟件行業的相關人員在整個軟件研發實施週期過程中，對軟件系統架構設計存在一定認識誤區。
下面是主要常見認識誤區。
01 架構 = 系統分析
- 宏觀而言，都需要對需求進行分析。
- 在傳統軟件開發過程中，系統分析更側重於解決某一領域問題，配合進行可行性分析，強調與客戶(需求方)的溝通，分析/討論/評估不確定的需求，給出系統的設計解決方案。
- 架構則是針對確定的需求進行分析，並充分考慮領域外的需求，對軟件系統提供結構、行爲和屬性的抽象，對軟件系統邏輯、運行、開發和部署各個方面給出表述。
02 架構 = 設計
- 架構是設計的一個表象，它關注關鍵元素，特別是對於性能、可靠性、成本、適用性等有重大影響的元素。
- 架構定義了一些重要的設計決策，是高層設計規約。
- 架構不關心每個獨立元素的詳細設計。
03 架構 = 藍圖
- 架構定義了基礎架構（藍圖），但更側重揭示架構元素間的互操作關係。
- 架構還需要表達代碼運行時的結構。
- 架構需要使用多個視圖，從多個維度表述不同涉衆的不同關注點。
04 架構 = 技術框架
- 框架實現了架構風格/模式所要求的一些設計規約。
- 框架是設計過程賴以實現的平臺，是開發架構的組成部分。
- 架構是一個動態過程，而框架是一個相對穩定的工具或者設計模型。
軟件系統架構設計
01 設計關注點
軟件系統架構是一個演進的過程，也可以理解是有生命週期的， 每一階段的架構都可能被新的架構推翻，沒有完美、恆定的架構。
進行架構設計時我們常關注下面四個方面：
架構關注的是設計的高層規約，不關注組成元素內部的細節。
國外相關書籍對“風格/模式“的一定義如下
一種架構風格是一組協作的架構約束，這些約束限制了架構元素的角色和功能，以及在任何一個遵循該風格的架構中允許存在的元素之間的關係。
好比我們常提及的面向對象、面向方面、服務組件化架構、SOA、ESB、微服務、消息總線、客戶端/服務端等等都是“風格/模式”。
02 應具備的特性
根據前面談到業務領域的架構特點，軟件系統架構設計也應具備如下幾點主要特性：
A. 相對性
B. 時效性
C. 前瞻性
D. 約束性
同時對於開發人員來說，技術架構作爲系統架構的一部分，好的架構還應該關注以下指標：
可靠性、可移植性、可重用、可配置、可定製、可擴展、可進化、可伸縮、效率、性能等。
（具體含義可參考相關的軟件架構設計書籍定義）
03 設計流程表述
關於如何開展軟件系統架構設計，綜合一些方法論和業界目前普遍的做法，歸納總結整體流程如下圖。
對於架構視圖，不同維度存在各種視圖，目前軟件行業內多采用一種軟件架構設計方法學：4+1視圖模型，使用了5種協作的視圖來對軟件架構的描述加以組織。每種視圖致力於解決一組特定的關注點。
以上爲4＋1視圖模型圖（摘自國外相關書籍），即場景視圖、邏輯視圖、開發視圖、過程視圖、物理視圖5種視圖描述。但實際過程中並非每種軟件系統架構都需要全部涉及到這5種視圖，需根據實際業務需求而定。
（4+1視圖模型詳細說明可參考相關書籍或網上資料）
04 實際設計參考維度
前面提到軟件系統架構設計所需關注的要點和方法理論，在目前軟件研發實施週期過程中，進行軟件系統架構設計時，系統架構師經常會考慮涉及的主要維度如下：
上圖也是我們實際軟件系統架構設計時，經常會用到的參考總圖，但並不是每種軟件系統都需要涉及到5個架構，需根據具體實際需求綜合考量使用。
（每種架構詳細說明可參考相關書籍或網上資料）
總結
以上只是關於軟件系統架構的概述，提及到的系統架構相關的定義、關注點、價值、目前業界流行的架構設計方法論。所有理論知識參考軟件系統架構設計相關書籍和之前多年項目實施經驗及驗證總結。
最後總結出來的經驗：需求是系統架構的前提，只有深刻理解需求，纔可能設計出優秀的軟件架構。沒有完美的軟件系統架構，只有適合的軟件系統架構；沒有不變的軟件系統架構，只有不斷演進變化系統架構。