作為程序員的我們近期目标可能是架構師，那麼如何快速成長為一名架構師呢？其實是有一些方法論的，但架構設計也不像程序設計一樣有固定的學習體系。接下來從什麼是架構設計、架構設計原則、架構設計思維、架構設計方法論四個方面來進行展開，架構設計除了掌握技術框架、技術組件、技術原理性知識外，也需要系統性掌握架構基礎知識，以架構設計原則、設計思維為指導，掌握架構設計方法論，通過不斷的優化和叠代，來實現更優秀的架構設計。

2.1 架構定義

百度百科：架構又名軟件架構，是有關軟件整體結構與組件的抽象描述，用于指導大型軟件系統各個方面的設計。軟件架構描述的對象是直接構成系統的抽象組件。各個組件之間的連接則明确和相對細緻地描述組件之間的通訊。

從定義中我們提煉出幾個關鍵字：組件、結構、連接。

組件：也可以稱為軟件元素或者是架構要素。可以是子系統、模塊、應用服務，取決于不同角度來看待。

結構：是架構之後的産出物，不同的軟件系統會有不同結構，這些結構為解決不同場景而設計。

連接：實現架構組件之間的連接。連接關系可以是JVM内部調用、可以是組件之間、可以是跨應用的分布式調用、也可以是與外系統接口集成調用。

總結：架構是将軟件組件按照一定結構連接起來的 。

軟件組件怎麼來找、用什麼結構來連接、如何來連接，這些都是軟件複雜度所帶來的問題。

架構設計本質就是解決軟件複雜度帶來的問題 ，最終實現降本增效。軟件複雜度表現形式有很多種，比如業務複雜度、性能複雜度、可用性複雜度、可擴展性複雜度、安全複雜度等；任何一個系統都有它側重解決的複雜度問題，理解每個架構方案背後需要真正解決的是軟件複雜度的什麼問題，是評判一個架構設計目的性的關鍵因素，這也是做架構設計中常提的系統約束條件 。

業務複雜度體現的是如何來拆解業務，找到合适的軟件元素和組件，按合适結構進行連接；性能複雜度體現的是找到軟件元素，進行合适連接形成一定結構，達到高性能要求。比如說一個大型ERP系統，屬于業務複雜度高的系統，你該如何去拆分它，拆分成一個個獨立完備、具有明确業務邊界的組件，這是做架構設計需要思考的。再比方說做一個秒殺系統，系統複雜度要求就是性能複雜度，怎麼能扛住秒殺的洪峰，這是性能複雜度需要解決的問題。

2.2 軟件開發和架構設計的區别

軟件開發 更多是面向确定性邏輯問題，依據自身對需求的理解進行實現，實現方式較為固定，流程化開發完成需求功能，實現最終目标。

比方說實現訂單接收的能力，分幾步：參數驗證、商品查詢、庫存預占、生成訂單、扣減庫存、修改訂單狀态、狀态回傳，業務邏輯較為固定，如果再加上編碼規範以及框架約束，除了數據模型以及編碼設計之外，其他方面涉及較少。

架構設計 更多是面向不确定性問題，怎麼将系統拆分成組件，怎麼去識别是不是組件、組件和組件之間怎麼進行連接，這些都是有很多種可能性的架構方案。在多種方案之間如何來決策需要一系列的原則來進行指導，最終選出最佳方案。

解決一個軟件複雜度問題方案，有方案A、方案B，甚至有方案C ，應該用哪種，原因是什麼，都是架構設計需要思考的問題。在多種方案之間如何來進行決策，如何判斷自己選擇的方案是合理的，當然決策能力也不是拍腦袋來決定的，它其實也需要一系列原則來進行指導，通過這些指導原則加上實際經驗來決策最優方案。

談到架構設計不得不說三個基本原則，作為架構設計過程中的參考，更好幫忙去做分析、做決策、做支持。

3.1、适合原則

首先提到就是适合原則 ， 一切不按實際場景出發的架構設計都是在耍流氓。

比如你 想買個車子，買貴覺得性價比不高，買便宜了覺得開起來不舒适，你最終會挑一個适合現在經濟能力範圍内又比較舒适的車子，這就是合适原則。

1）、以當前業務需求和非功能性需求為目标，匹配業務發展所處階段，合理利用資源發揮最大價值（買車子需要匹配當前經濟狀态）；

2）、需要結合實際場景，合适的系統架構 （我買車子隻是為了代步，不能說我覺得跑車氣派，我就買個跑車，這和業務實際場景不符合）；

3）、考慮業務近1到2年的發展規模。

還需要和當前的業務規模以及最近1-2年的發展規劃相互匹配 （雖然我一次性付不起，但有穩定經濟收入，我可以考慮貸款，分2年期。這樣我既買到理想的車型，也不擔心壓力大）；新技術推出，勢必是解決某一場景下的問題，但并不能解決所有問題，任何架構都要綜合來看，結合合适原則綜合選擇。

3.2、簡單原則

其次是 簡單原則 ，大道至簡，一切簡單化，用最簡單的解決方案來解決問題 。

KISS （Keep Simple and Stupid）原則是用戶體驗的最高境界，同樣它适用于架構設計 ；簡單是軟件設計的目标，簡單代碼占用的時間少，産生的漏洞少，并且易于修改 、維護、擴展和重構；不要以為簡單設計是沒有技術含量，用簡單設計處理複雜問題更需要優秀的架構設計能力；軟件系統之所以會被說成複雜，體現在 結構複雜 以及 邏輯複雜 ，而一個複雜問題是由多個簡單問題構成的，難的是如何拆解它，将它拆解為多個問題，逐個解決，把複雜邏輯拆分為一個個單一執行單元，單個執行單元代碼量一定要盡可能少。邏輯複雜系統在内部實現所有邏輯功能，幾乎會導緻每個環節都有問題，它需要面對不斷變化的需求，所有人維護同一套代碼，整個開發、測試、上線流程變得異常繁重。

3.3、演化原則

最後是演化原則 ，隻有變化是永恒不變的 ，優秀架構一定是以業務不斷發展而不斷演進而來；設計架構要滿足當時業務需要 ，具有可擴展性和持續開發能力，能夠應變後續架構升級和調整；要不斷地在實際應用過程中叠代，保留優秀設計，修複有缺陷設計，改正錯誤設計，剔除無用設計，使架構逐漸完善，要将變化部分和不變部分區分開。可以看下《淘寶從幾百到千萬級并發的十四次架構演進之路》。在數字化領域，技術和業務都可能處在快速的變化中，架構是需要通過目标架構的設想和差距分析等架構方法來處理當前和長遠的關系。

要想做好架構設計必須具備的架構設計思維，主要有以下三種思維：抽象思維；分治思維；複用思維。

4.1、抽象思維

架構是為了滿足業務需求而存在，需要通常是一些文字性的描述、原型、UI設計圖，這些最終都會變成代碼讓機器執行。我們必須先進行抽象，把需求變成計算機能識别的模型。

例如，抽象出各個用戶、訂單、内容等模型，劃清各個角色的責任以及對象交互的方式，隐藏很多無關緊要的細節。

4.2、分治思維

對複雜的系統分而治之，分解為小的、簡單的部分。我們通常所說的通過增加一層來解決問題即是分治的一種體現，分類分層是把複雜問題簡單化，化整為零，分别進行處理。例如針對高并發場景，可以通過設計将流量分發到不同的服務器，避免單台服務器過載。又例如，将一個大泥鳅系統通過DDD領域設計驅動的方法論去設計，絞殺者模式去拆解、重構。但光分解還是不夠的，同時還需要保證分解後的部分能夠通過約定好的協議集成在一起。

4.3、複用思維

複用是提升開發效率的最簡單有效的方法，通過對相同内容的抽象，讓其能複用于不同的場景。

很多新手程序喜歡複制粘貼代碼，如果需求變化，需要修改所有粘貼過的地方，開發效率低且難以維護，同時還浪費很多測試的精力。

複用是最佳的軟件工程實踐，沒有之一。複用可以給我們帶來以下好處：

• 較高的生産率。• 較高的系統質量。• 改善系統的可維護性。

所以，我們在進行架構設計時也需要使用複用思維，将各個模塊需要用到的共性功能抽取為可複用的共性組件。

我們可以将複用分為常規複用和系統層複用。其中常規複用又可分為代碼複用、算法複用、數據結構的複用；系統層複用又可分為設計複用、分析複用。

以上三種設計思維在架構設計中都很重要、且相輔相成，但并不是把每一項做到極緻，而是需要在設計中去平衡各個思維，因為架構設計的本質是解決軟件複雜度帶來的問題，最終實現降本增效。

提到架構設計方法論，有企業架構（EA）框架：Zachman框架 ，還有國際權威組織結構制定的行業标準的體系架構框架 Togaf。

一個好的框架（Framwork）有三個不同的方面：描述内容（結構、元模型）；描述過程（什麼活動需要什麼順序發生）；描述組織（參與架構的人員、角色）

Togaf涵蓋了這三方面，而Zachman框架隻涵蓋了内容，即内容框架。

接下來就介紹下 TOGAF（The Open Group Architecture Framework），它由國際标準權威組織The Open Group制定 ，是一個行業标準的體系架構框架 。它是一套方法和工具，主要包含TOGAF能力框架、 TOGAF架構開發方法、 TOGAF企業連續體和工具三大部分。

下面主要介紹下軟件開發方法 （Architecture Development Method) ADM，它以一個循環叠代模型為基礎将企業架構的建設過程劃分為前後銜接的若幹步驟，并對每個步驟的輸入、輸出以及所采用方法都進行了詳盡的闡述。描述了一種開發和管理企業架構生命周期的方法。

5.1、 ADM架構開發方法——基礎結構圖

ADM 軟件開發方法是由一組按照架構領域的架構開發順序而排列成一個環的多個階段所構成的，ADM基礎結構圖如下圖所示。

ADM基礎結構圖

ADM葫蘆圖概括為“一備一中心，八步一方法”（一個預備階段、以需求管理為中心，八個主體步驟，一套方法ADM）

預備階段：梳理業務需求，了解需求背後真實的業務目标。

架構願景：最終需要達成到一個效果，需要提前做規劃。

業務架構、信息系統架構、技術架構：屬于架構域設計框架。

技術及解決方案：碰到技術問題都需要有一套甚至是多套解決方案，架構設計職責就是做取舍、做決策。

遷移規劃、實施治理：後續線上運維相關事項，給出合理解決方案。

需求管理：項目的每個階段都應基于并驗證業務需求。

TOGAF描述了四類跨階段叠代：預備階段和階段A之間的 架構能力叠代 ，階段B-F之間的 架構開發叠代 ，階段E、F的 過渡規劃叠代 ，以及階段G、H和預備階段之間的 架構治理叠代 。

架構設計方法論：是指導你如何來做架構設計，它有架構域劃分，在軟件設計中架構域包括：業務架構、數據架構、産品架構、應用架構、技術架構。

首先需要進行業務需求結合業務場景的梳理，熟悉業務後，通過歸納以及抽象的方式，形成業務架構。

依據業務架構的理解，研發人員需要對業務做進一步的抽象和沉澱，畫出與之相對應的數據架構和應用架構，最後技術人員通過技術架構來做功能實現。

業務架構是目标、是方向，應用架構是抽象、是歸納，技術架構是手段、是系統落地的參考物。

5.2、ADM架構開發方法——概念藍圖

ADM架構開發概念藍圖

左側部分是企業的業務戰略、目标、挖掘業務需求給出業務解決方案。中間部分是通過業務架構設計、數據架構設計、應用架構設計、技術架構設計給出技術解決方案。右側部分技術解決的方案通過應用、項目去承載、在滿足功能的基礎上實現系統高性能及智能化。解決業務的複雜性，最終實現降本增效。

我們重點關注下中間部分架構設計，架構域分類：

1、 業務架構：講需求描述轉變成業務目标，梳理出信息業務流程和業務元素。

2、 數據架構：描述數據資産及數據管理資源的結構。

3、 應用架構：劃分不同功能模塊、根據功能模塊的關系，組合成子系統。

4、 技術架構：支持業務、數據、應用部署所需的軟件與硬件能力。

熟悉業務，形成業務架構，根據業務架構，做出數據架構和應用架構，最後通過技術架構落地實施。

5.2.1、業務架構

首先來看 業務架構 = 業務目标 業務流程 業務要素。

業務架構最重要的是識别出業務流程和業務流程中包含的業務要素，換個角度來看就是業務要素與業務要素之間的關系，這些關系組成了整個業務。

業務一般會按照 場景層、産品功能層、領域模型層、依賴層這四層畫出業務架構圖。

場景層：描述業務場景；産品功能層：劃分産品功能以及模塊；領域模型層：通過對産品功能分析，抽象領域模型；依賴層：從業務層面考慮涉及到底層業務依賴哪些子系統或者組件。

業務架構示例：業務目标 業務架構圖. 業務目标：SAAS平台實現開戶即用。用戶根據所有應用的權限進行應用功能的訪問，統一訪問入口、控制請求（按應用、租戶去路由到指定應用集群上）并進行應用治理。

5.2.2、數據架構

其次是 數據架構 ：由業務架構驅動，從業務架構分析業務流程，分析領域模型層，從領域模型層觸發構建數據架構。

數據架構解決的是，第一，需要什麼數據；第二，怎麼存儲；第三，如何設計。

數據模型最常用視圖就是ER圖，它主要描述數據實體、屬性和關系。

實體（Entity）：領域對象；

屬性（Attribute）：領域對象屬性；

聯系（RelationShip）：兩個領域對象之間的關系（1:1，1:n或者）。

數據架構示例：

5.2.3、應用架構

再就是 應用架構 ，應用架構劃分出不同功能模塊，再根據功能模塊間的關系，組合成子系統。應用架構考慮三個問題。

第一，子系統如何劃分；第二，子系統之間什麼關系；第三，考慮模塊的複用和功能的抽象。

應用架構需要體現應用架構是否清晰、層次劃分是否明确、各應用系統之間連接關系 是否合理、系統之間耦合程度是否低、是否以統一方式對外提供一緻服務接口。

應用架構示例：

5.2.4、技術架構

最後是 技術架構 ，技術架構關注的問題有，如何使用技術手段來解決實際問題、技術框架如何選擇、技術中間件如何選擇、存儲如何來做、非功能性需求如何來實現等。整體技術方案的輸出就是實現技術架構的過程，最終會形成關鍵技術實現要點，形成一個完整的技術架構。

總結技術架構涉及到技術問題、技術方案、及技術組件。通過各種技術組件形成技術方案，最終解決業務上的技術問題。技術組件可以是分布式緩存、消息隊列、分布式定時任務等，同時包括硬件能力、包括IT技術設施、網絡、通信、标準等。

技術架構圖示例：

部署架構圖示例：

本文主要從什麼是架構設計、架構設計原則、架構設計思維、架構設計方法論四個方面來進行闡述，架構設計除了掌握技術框架、技術組件、技術原理性知識外，也需要系統性掌握架構基礎知識，以架構設計原則、設計思維為指導，掌握Togaf架構設計方法論，通過不斷的優化和叠代，來實現更優秀的架構設計。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!