架構是什么？業界并沒有權威的說法。
架構作為名詞與結構相關，將產品分解為一系列組件、模塊和交互。作為動詞，是關于交流愿景和引入技術領導力的，簡而言之，架構就是結構和愿景。
關于架構
應用程序的架構著重于軟件和代碼的組織，每個工程師的代碼都是有架構的，只是自發和自覺的區別；系統架構描述從組件和服務到子系統等更高層次的抽象含軟硬件，從代碼結構到生產環境，與軟件系統重要元素相關的所有東西就是軟件架構。
企業架構是一個截然不同的概念，指的是戰略而非代碼。
所有架構都是設計，但并非所有設計都是架構。架構反映了一個系統的重要設計決策，重要性通過改變的成本來衡量，包括系統的形態，結構，技術選擇，框架選擇，設計方法和模式的選擇等。
敏捷與架構并不沖突，敏捷中的架構是在獨特環境下量化所需的預先設計，架構提供了xDD敏捷方式的分界線。主要思想是集中主要的高層次關鍵需求，規避風險，然后迭代和增量。敏捷是相對的，好的架構能夠帶來敏捷，尤其是微服務架構。
非功能性需求
需求是最重要的事情，失去了功能，失去了客戶的價值，軟件將一無是處。
然而，功能的實現只是架構的開端。
架構首先來自需求，需求驅動架構，然后非功能性需求反映服務等級，面對客觀環境的約束，自行引入的架構實現原則，是在高層次以上對需求、約束、和原則的理解和把握。
非功能性需求也可以稱為質量屬性，我所了解的非功能性需求主要有：
- 性能：響應時間或延遲
- 可伸縮性：更多用戶，請求和數據的處理能力
- 可用性：99.9%意味著每天一分鐘故障
- 安全性： 可以參考OWASP，open web application security project
- 災難恢復：業務連續性過程
- 可訪問性：www.w3.org/standards/webdesign/accessibility
- 監測：只讀視圖
- 管理：操作視圖
- 審計：日志及虛擬貨幣的對賬
- 靈活性：非技術人員修改業務規則的能力
- 可擴展性：可以做現在還不能做的事情
- 可維護性：可讀性，可持續發展
- 法律規則：如隱私
- 國際化i18n
- 本地化i10n
約束
時間和預算是約束的基本條件。
技術約束
技術清單，現有系統的互操作性（兼容性），目標部署平臺，技術成熟度（保守），開源技術，供應商關系（阿里云，還是AWS），過去的失敗，內部知識產權
人員約束
團隊規模，技能，團隊擴展的速度，咨詢和培訓，運維團隊的技能
組織約束
企業戰略的影響，辦公室政治的影響
約束條件也是有優先級的。
原則
開發原則
編碼標準和規范，自動化單元測試，靜態分析工具
架構原則
- 分層策略，如UI組件里沒有數據訪問的邏輯
- 業務邏輯的位置：
- 高內聚、低耦合：解耦合可以推遲技術決策的時間
- 無狀態組件：可伸縮性的瓶頸
- 存儲過程：愛恨交加
- 域模型：面向對象的豐富程度
- http會話的使用程度：少用
- 始終一致和最終一致： 一般趨向于數據的最終一致性
- 不/使用ORM
- 依賴注入
風險
架構包含技術的選擇，更多分層等于更高的復雜度，但是輕量級協同設計可以提高質量。最佳實踐也是有使用條件限制的，面對架構要用于質疑。
系統的最大風險
外部接口是系統風險最高的部分之一。
- 關鍵的外部接口有哪些？接口的技術定義是什么？
- 哪些隊列是通信組件？消息的格式是什么？
- 同步還是異步？異步連接是否有保障？能否亂序傳輸？
- 接口是否冪等？接口的可用性、性能、可伸縮性、安全性？
- 接口的所有權屬？版本的升級處理？服務級別？
系統的常見風險
除了外部接口之外，其他的常見風險如下：
- 組件運行過慢
- 組件無法伸縮
- 關鍵組件崩潰
- 單點故障
- 數據被破壞
- 基礎設施故障
- 磁盤滿
- 新技術過于復雜
文檔
架構需要以文檔的方式回答質疑。
代碼不會講述完整的故事，輕量級文檔來描述代碼之外的問題，如
- 這是關于什么的？希望能做什么？
- 質量屬性？約束？原則？
- 軟件架構？外部接口？
- 數據（數據比軟件本身更重要。）？
- 基礎設施架構？
- 部署？運營和支持？
- 決策日志
……
總而言之，架構不論你關注與否都在那里，每個人都是架構師，只是關注的層面和視角不同而已。
Without architect consideration，the software is a big mall of mud。
