摘要
這是一篇架構師思考方法論的學習筆記，原文對什麼是架構，什麼是架構師，架構師如何定義和分析問題進行了比較深刻的探究。
一，什麼是架構
架構的三要素：
- 職責明確的模塊或者組件
- 組件間明確的關聯關係
- 約束和指導原則
三要素是關於架構這個名詞通用的定義，不侷限於軟件開發領域。下面具兩個例子便於理解：
例1：軟件架構
- 模塊：模型、域
- 關係：一對一、一對多（模型）；依賴（域）
- 原則：單一職責、開閉原則、里氏替換原則等等
例2：組織架構
- 模塊：部門
- 關係：管理 or 上報
- 原則：各種管理原則、財務原則
下面我們具體討論的還是軟件開發中的架構。
二，什麼是架構師
架構師這個角色的職責是：識別並定義問題，創建、選擇或調整架構，從而找到最優的方案，解決問題。
這其實也是架構師做事的一般套路：定義問題->確定架構->提出方案->落地拿結果。這四步中，越是前面的步驟，越是重要，越是抽象，也越是困難，越能體現架構師的功力。因此有必要探討下如何識別定位問題。
1， 區分問題、手段和挑戰
三個概念並不是相互嚴格區分的，它們是問題樹的不同層次。
每一個問題可以向下不斷展開不斷細化，下一級的問題是上一級問題的具體解決手段，當你把“提升性能”當做你Owner的問題時，提升幀率、提高頁面秒開率、優化啓動耗時就成爲了你的具體解決手段；而手段的下一級問題，就是你將面臨的挑戰，比如你要優化網絡耗時，你要面臨的挑戰就有弱網環境、一些國家區域的帶寬問題等等。
2，如何定義問題
亨利福特說，如果我問客戶需要什麼，他們會告訴我，他們需要一匹更快的馬。
定義問題經常需要思考問題背後的問題，爲什麼客戶需要一匹更快的馬？可能客戶想要更快的日常交通方式，上升了一個層次後，我們立刻找到了更好的解決方案：造車。
理論我們知道了，但給你個具體的問題描述你可能還是不知道如何準確定位背後問題。這裏有一實操技巧：我們可以不斷縮短描述問題句子，比如提煉主謂賓，如果還不能清晰的描述那麼在這幾個詞裏再找出最最最關鍵的詞，尤其是主語或者賓語中的詞彙非常重要，它有可能就是重點。
3，從哪些方面分析一個問題
可以從主要次要，緊急程度和時間維度三個角度分析。
前兩個維度看着是否很眼熟，有點像很多工作效率方法說的將事情的分類。這裏就不多說了。時間維度是容易被忽略的重要維度，任何一個問題的嚴重程度都有一個時間軸，也許過了某個時間點之後，問題便不再是個問題。
後面兩節，介紹架構師工作中要弄清的概念，幫助大家在和不同職位的人溝通時提升效率。
三，架構的分類
和業務需求方、產品經理、技術設計聊天，他們都會提到架構，但他們口中的架構不是一回事。區分清楚工作中常用的架構分類，可以讓你在開會時把不同職位的人口中的架構對號入座，以提升溝通效率。
| 名稱 | 受衆 | 目的 | 內容 |
|---|---|---|---|
| 產品功能架構 | 產品使用者，產品經理 | 指導用戶，吸引用戶 | 從用戶角度，闡述產品功能模塊 |
| 業務能力架構 | 研發人員，業務人員 | 用於理解業務內在的概念和聯繫,有助於我們分析和理解業務需求 | 業務能力，能力中的子能力 |
| 應用邏輯架構 | 研發人員，架構師，技術管理者 | 指導軟件研發 | 闡述架構中各模塊的職責：如系統模型，技術模塊，技術模塊的關係，技術模塊的核心抽象，如何用設計模式來讓架構符合軟件設計原則，等等 |
| 應用物理（部署）架構 | 運維人員，架構師，技術管理者 | 指導運維部署軟件 | 邏輯架構如何落地，比如使用何種微服務容器，邏輯架構的模塊落地時應該是package，還是應用，是不是要跨機房部署等等 |
| 基礎設施架構 | 架構師，技術管理者 | – | 選擇什麼樣的中間件，存儲，監控等等 |
四，能力和職責的區別
產品同學一般講能力，而架構同學一般講職責，區別如下：
能力
指一個產品能做什麼，如中臺本身是一個產品，對使用中臺的人來說，我們應該講中臺的能力。
職責
指架構內模塊的職責，用來指導開發。比如對中臺的研發，應該講架構的職責，依賴，約束。
簡答來說，能力是對產品的使用者來說的，職責是對架構的實現者說的。