架構師是一個既能掌控整體又能洞悉局部瓶頸並依據具體的業務場景給出解決方案的團隊領導型人物。看似完美的“人格模型”背後，是艱辛的探索。今天，將阿里巴巴技術專家多年經驗系統性總結的文章分享給大家，希望更多架構師在進階這條路上走得更“順暢”，姿態更“優雅”。
架構師職責
架構師不是一個人，他需要建立高效卓越的體系，帶領團隊去攻城略地，在規定的時間內完成項目。
架構師需要能夠識別定義並確認需求，能夠進行系統分解形成整體架構，能夠正確地技術選型，能夠制定技術規格說明並有效推動實施落地。
按 TOGAF 的定義，架構師的職責是瞭解並關注實際上關係重大但未變得過載的一些關鍵細節和界面，架構師的角色有：理解並解析需求，創建有用的模型，確認、細化並擴展模型，管理架構。
從業界來看對於架構師的理解可以大概區分為：
- 企業架構師：專注於企業總體 IT 架構的設計。
- IT 架構師-軟件產品架構師：專注於軟件產品的研發。
- IT 架構師-應用架構師：專注於結合企業需求，定製化 IT 解決方案；大部分需要交付的工作包括總體架構、應用架構、數據架構，甚至部署架構。
IT 架構師-技術架構師：專注於基礎設施，某種軟硬件體系，甚至雲平臺，提交產品建議、產品選型、部署架構、網絡方案，甚至數據中心建設方案等。
架構師職責明確了，那麼有什麼架構思維可以指導架構設計呢？
請看下述的架構思維。
架構思維
1、自頂向下構建架構
要點主要如下：
1）首先定義問題，而定義問題中最重要的是定義客戶的問題。定義問題，特別是識別出關鍵問題，關鍵問題是對客戶有體感，能夠解決客戶痛點，通過一定的數據化來衡量識別出來，關鍵問題要優先給出解決方案。
2）問題定義務必加入時間維度，把手段/方案和問題定義區分開來。
3）問題定義中，需要對問題進行升層思考後再進行升維思考，從而真正抓到問題的本質，理清和挖掘清楚需求；要善用第一性原理思維進行分析思考問題。
4）問題解決原則：先解決客戶的問題（使命），然後才能解決自己的問題（願景）；務必記住不是強調我們怎麼樣，而是我們能為客戶具體解決什麼問題，然後才是我們變成什麼，從而怎麼樣去更好得服務客戶。
5）善用多種方法對客戶問題進行分析，轉換成我們產品或者平臺需要提供的能力，比如倉儲系統 WMS 可以提供哪些商業能力。
6）對我們的現有的流程和能力模型進行梳理，找到需要提升的地方，升層思考和升維思考真正明確提升部分。
7）定義指標，並能夠對指標進行拆解，然後進行數學建模。
8）將抽象出來的能力訴求轉換成技術挑戰，此步對於技術人員來說相當於找到了靶子，可以進行方案的設計了，需要結合自底向上的架構推導方式。
9）創新可以是業務創新，也可以是產品創新，也可以是技術創新，也可以是運營創新，升層思考、升維思考，使用第一性原理思維、生物學（進化論--進化=變異+選擇+隔離、熵增定律、分形和湧現）思維等哲科思維可以幫助我們在業務，產品，技術上發現不同的創新可能。可以說哲科思維是架構師的靈魂思維。
2、自底向上推導應用架構
先根據業務流程，分解出系統時序圖，根據時序圖開始對模塊進行歸納，從而得到粒度更大的模塊，模塊的組合／聚合構建整個系統架構。
基本上應用邏輯架構的推導有4個子路徑，他們分別是：
- 業務概念架構：業務概念架構來自於業務概念模型和業務流程；
- 系統模型：來自於業務概念模型；
- 系統流程：來自業務流程；
- 非功能性的系統支撐：來自對性能、穩定性、成本的需要。
效率、穩定性、性能是最影響邏輯架構落地成物理架構的三大主要因素，所以從邏輯架構到物理架構，一定需要先對效率、穩定性和性能做出明確的量化要求。
自底向上重度依賴於演繹和歸納。
如果是產品方案已經明確，程序員需要理解這個業務需求，並根據產品方案推導出架構，此時一般使用自底向上的方法，而領域建模就是這種自底向上的分析方法。
對於自底向上的分析方法，如果提煉一下關鍵詞，會得到如下兩個關鍵詞：
1）演繹：演繹就是邏輯推導，越是底層的，越需要演繹：
- 從用例到業務模型就屬於演繹；
- 從業務模型到系統模型也屬於演繹；
- 根據目前的問題，推導出要實施某種穩定性措施，這是也是演繹。
2）歸納：這裡的歸納是根據事物的某個維度來進行歸類，越是高層的，越需要歸納：
- 問題空間模塊劃分屬於歸納；
- 邏輯架構中有部分也屬於歸納；
- 根據一堆穩定性問題，歸納出，事前，事中，事後都需要做對應的操作，是就是根據時間維度來進行歸納。
3、領域驅動設計架構
大部分傳統架構都是基於領域模型分析架構，典型的領域實現模型設計可以參考DDD（領域驅動設計），詳細可以參考《實現領域驅動設計》這本書，另外《UML和模式應用》在領域建模實操方面比較好，前者偏理論瞭解，後者便於落地實踐。
領域劃分設計步驟：
1）對用戶需求場景分析，識別出業務全維度 Use Case。
2）分析模型魯棒圖，識別出業務場景中所有的實體對象。魯棒圖 —— 是需求設計過程中使用的一種方法（魯棒性分析），通過魯棒分析法可以讓設計人員更清晰，更全面地瞭解需求。它通常使用在需求分析後及需求設計前做軟件架構分析之用，它主要注重於功能需求的設計分析工作。需求規格說明書為其輸入信息，設計模型為其輸出信息。它是從功能需求向設計方案過渡的第一步，重點是識別組成軟件系統的高級職責模塊、規劃模塊之間的關係。魯棒圖包含三種圖形：邊界、控制、實體，三個圖形如下：
3）領域劃分，將所有識別出的實體對象進行分類。
4）評估域劃分合理性，並進行優化。
4、基於數據驅動設計架構
隨著 IoT、大數據和人工智能的發展，以領域驅動的方式進行架構往往滿足不了需求或者達不到預期的效果，在大數據時代，在大數據應用場景，我們需要轉變思維，從領域分析升維到基於大數據統計分析結果來進行業務架構、應用架構、數據架構和技術架構。這裡需要架構師具備數理統計分析的基礎和 BI 的能力，以數據思維來架構系統，典型的系統像阿里的數據分析平臺採雲間和菜鳥的數據分析平臺 FBI。
上述四種思維，往往在架構設計中是融合使用的，需要根據業務或者系統的需求來選擇側重思維方式。
有了架構思維的指導，具體有沒有通用／標準化的架構框架以更好的執行架構設計？請看常見的架構框架。下述的架構框架其實本身也包含了重要的一些架構思維。
閱讀更多 程序員瓦力 的文章
