另讀：《一線架構師實踐指南》

感慨：大概看這本書對於現在的我來說還太早，經驗不足，先成為一個好的程式設計師吧……以後再回來看這本書

第1章 從程式設計師到架構師

第2章 解析軟體架構概念

Architecture架構，每個人的理解都不同。
分為組成派和決策派。
組成派：軟體系統的架構將系統描述為計算元件以及元件之間的互動（The architecture of a software system defines that system in term of computational components and interactions among those components. ）。更多地關注軟體，分析軟體組成。
決策派：某個軟體或計算機系統的架構是該系統的一個或多個結構，每個結構均由軟體元素、這些元素的外部可見屬性、這些元素之間的關係組成（The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. ）。更關注人，歸納了架構決策的型別。
系統、子系統、框架都可以有架構，只是粒度不同。
架構不僅僅是介面的問題，還有併發、部署、效能、安全等因素需要考慮設計方案，而分層很重要，迭代地細化設計，並且靈活應用設計模式。

第3章 理解架構設計檢視

架構設計需要面向：使用者、客戶、開發人員、管理人員等，為專案相關不同人員而設計。
物理檢視+邏輯檢視。
使用分而治之和迭代式設計（而非瀑布式）。
經歷設計在前，成為架構師在後。
儘量找機會看看別人的設計成果、多體會別人的設計過程、多試著自己來設計設計。

第4章 架構設計過程

程式設計師向架構師轉型難在哪裡？難在必須要能開始“試著做起來”，並慢慢積累感覺，進而積累經驗。
洞察節奏3個原則：1、看透需求（基礎）；2、架構大方向正確（確定正確的概念架構）；3、設計好架構的各個方面（通過多檢視方法“細化架構”，通過“架構原型”驗證架構）。
看透需求：需求要全（功能需求、質量需求、約束需求），矛盾關係，追溯關係（如追溯系統目標）。
架構大方向正確：概念架構，是策略，如架構模式、整合技術選型。（重要！！！直指系統設計目標的設計思想和重大選擇，是關乎任何複雜系統成敗的最關鍵的指向性的設計。對比分析幾種可能的概念架構）
設計好架構的各個方面：架構師必須具備“忘卻”的能力，避免設計太多具體的技術細節，5檢視。
有經驗的架構師不會一上來就關注如何定義“介面”，他們在大型系統架構設計的早期比較注重識別：重大需求；特色需求；高風險需求；據此來決定如何劃分頂級子系統，採用什麼架構風格和開發技術，整合是否要支援，二次開發是否要支援（1個決定4個選型）。
掌握過程6個步驟：（1）需求分析（2）領域建模（3）確定關鍵需求（4）概念架構設計（5）細化架構設計（模組+介面）（6）架構驗證（對後續工作產生重大影響返工代價很高的任何工作都應該進行驗證，包括需求和架構設計方案）。
領域建模：以提煉領域概念，建立領域模型為目的的活動。精髓是“業務決定功能，功能決定模型”。領域建模活動的輸入：功能和可擴充套件性具體要求。

第5章 需求分析

願景分析：要解決專案、產品或解決方案的起源問題。所謂明確願景，就是針對系統目標、主要特性、功能範圍、成功要素等進行構思並達成一致。（需求分析，得到需求文件）
願景=業務目標+規範+Feature+上下文圖。
《軟體需求規格說明書》（Software Requirements Specification, SRS）需求分層次，需求分不同方面。
ADMEMS矩陣（需求層次-需求方面矩陣）
軟體質量：執行期質量屬性和開發期質量屬性。（效能，安全性，易用性，持續可用性，可伸縮性，互操作性，可靠性，魯棒性，易理解性，可擴充套件性，可重用性，可測試性，可維護性，可移植性）
約束需求=業務環境因素+使用環境因素+構建環境因素+技術環境因素
需求=功能+質量+約束

第6章 用例與需求

用例技術族：用例圖，用力簡述（使用者故事），用例規約，用例實現（魯棒圖）。

第7章 領域建模

領域模型：就是將領域概念（即領域行話）以視覺化的方式抽象成一個或一套模型。是探索問題領域的工具，而已幫助我們探索和提煉問題領域的知識。
就UML而言，領域模型最常採用：類圖和狀態圖。
需求人員視角：促進使用者溝通，解決分析癱瘓。
功能決定如何建模，模型決定功能擴充套件。（要考慮多種情況以及未來可能）
多個專案可能共享某任務。

第8章 確定關鍵需求

什麼決定了架構：用例驅動論，質量決定論，經驗決定論。
關鍵需求決定了架構。
確定關鍵質量，確定關鍵功能。
小系統與大系統的分水嶺。
拿來主義需要經過對比。

第9章 概念架構設計

概念架構是直指目標的設計思想、重大選擇。
概念架構界定系統的高層元件、以及他們之間的關係。概念架構意在對系統進行適當分解，而不陷入細節。藉此，可以與管理人員、市場人員、使用者等非技術人員交流架構。概念架構規定了每個元件的非正規的、以及架構圖，但不涉及介面細節。
魯棒圖：邊界物件，控制物件，實體物件。
1個決定4個選擇：決定如何劃分頂級子系統，架構風格選型，開發技術選型，二次開發技術選型，整合技術選型。

第10章 細化架構設計

5個檢視。15個設計任務。
邏輯架構（模組劃分、介面定義、領域模型），開發架構（技術選型、檔案劃分、編譯關係），執行架構（技術選型、控制流劃分、同步關係），物理架構（硬體分佈、軟體部署、方案優化），資料架構（技術選型、儲存格式、資料分佈）。

第11章 架構驗證

不值得驗證的架構，就不值得設計。
原型技術分類和用途：水平原型（行為原型）vs垂直原型（結構原型），拋棄原型（探索原型）vs演進原型（同增量開發思想）。
驗證架構：原型法和框架法。框架法更適用於產品型開發。測試執行期質量，評審開發期質量。

第12章 粗粒度“功能模組”劃分

掌握模組劃分技巧，我們分4步進行，涉及，日常涉及工作常用的功能樹、分層框架、用例模組、模組化等技巧：（1）粗粒度的“功能模組”劃分，應該怎麼做（2）如何分層，如何分別封裝各種“外部互動”？（3）從用例（需求）到模組劃分結構（設計）的具體步驟？（4）水平切分（層）不等於垂直切分（功能模組）不等於通用專用分離。細粒度模組化時，這樣綜合利用多種模組劃分技巧？
藉助功能樹，劃分粗粒度“功能模組”。
從“功能樹”到“功能模組”是粗粒度功能模組劃分的常用手段。
僅僅是“業務模組劃分結構”會帶來三大問題：（1）後續研發任務不明確（2）細粒度功能上有重疊（3）程式碼級重複在所難免。

第13章 如何分層

“學樣兒”未必合適，“知其所以然”才是王道。
常見分層：展現層+業務層+資料層，UI層+SI層+PD層+DM層，
分層架構的“封裝外部互動”思想；設計分層架構，從上下文圖開始。

第14章 用例驅動的模組劃分過程

描述需求的序列圖vs描述設計的序列圖
從用例到類，再到模組。

第15章 模組劃分的4步驟方法-運用層、模組、功能模組、用例驅動

封裝驅動設計方法EDD：細粒度劃分。綜合運用分層、分層細化、功能模組、通用模組、通用機制框架化等多種手段，是該方法的特點。步驟：研究需求，粗粒度分層，細粒度劃分模組，用例驅動的模組劃分結構評審、優化。