看到本書第十三章發現，需求不應該決定架構，我心想：what？架構不就是要根據使用者需求來確定的嗎。再往下看，原來是關鍵需求決定軟體架構。
究其原因也很好理解，在實際軟體開發中，不是像大學裡這種「實驗室**」，軟體架構師沒有時間對『所有需求』進行深入分析，這既是策略，也是現實，當然這對於我以後走向社會提供了很大幫助，轉化了一種思路。俗話說，事無鉅細，但這在軟體架構設計階段並不適用，姑且不論使用者的需求經常變化，反覆無常，要想兼顧所有的需求那是不可能的，所以確定關鍵需求至關重要。結合課上所學知識，相互印證，一般可以從功能需求、質量需求和商業需求三方面來進行分類。任何功能需求，都是由一條特定的『模組協作鏈』完成的。
一方面，不同質量屬性之間往往具有相互制約性，於是我們自然應該權衡哪一部分質量屬性是架構設計的重點目標。另一方面，功能需求數量眾多，應該控制架構設計時需要詳細分析的功能（或用例）的個數。
可通過如下4條啟發規則，確定關鍵功能子集：
只要能較好地覆蓋組成架構的不同職責模組，並體現職責模組之間協作關係的特點，那麼「關鍵功能子集」的價值也就體現出來了。為什麼架構師的經驗很重要呢，確定「關鍵需求」靠的就是經驗，目的是用有限的時間針對關鍵需求把設計做到位、並減小需求變更對架構設計的影響。這也就是為什麼軟體架構師比較難做，做好就更不用說了，你既要有多年的軟體開發而經驗，也就是心中有「貨」，又要當機立亂，不能猶豫，確定出本軟體最核心的功能是什麼，就像硬碟一樣，要求讀取速度快，就不能要求磁碟利用率高；要保證充分利用磁碟，節省空間，就無法注重讀取速度，所以要學會取捨。
看到本書第十三章發現，需求不應該決定架構，我心想：what？架構不就是要根據使用者需求來確定的嗎。再往下看，原來是關鍵需求決定軟體架構。
究其原因也很好理解，在實際軟體開發中，不是像大學裡這種「實驗室**」，軟體架構師沒有時間對『所有需求』進行深入分析，這既是策略，也是現實，當然這對於我以後走向社會提供了很大幫助，轉化了一種思路。俗話說，事無鉅細，但這在軟體架構設計階段並不適用，姑且不論使用者的需求經常變化，反覆無常，要想兼顧所有的需求那是不可能的，所以確定關鍵需求至關重要。結合課上所學知識，相互印證，一般可以從功能需求、質量需求和商業需求三方面來進行分類。任何功能需求，都是由一條特定的『模組協作鏈』完成的。
一方面，不同質量屬性之間往往具有相互制約性，於是我們自然應該權衡哪一部分質量屬性是架構設計的重點目標。另一方面，功能需求數量眾多，應該控制架構設計時需要詳細分析的功能（或用例）的個數。
可通過如下4條啟發規則，確定關鍵功能子集：
只要能較好地覆蓋組成架構的不同職責模組，並體現職責模組之間協作關係的特點，那麼「關鍵功能子集」的價值也就體現出來了。為什麼架構師的經驗很重要呢，確定「關鍵需求」靠的就是經驗，目的是用有限的時間針對關鍵需求把設計做到位、並減小需求變更對架構設計的影響。這也就是為什麼軟體架構師比較難做，做好就更不用說了，你既要有多年的軟體開發而經驗，也就是心中有「貨」，又要當機立亂，不能猶豫，確定出本軟體最核心的功能是什麼，就像硬碟一樣，要求讀取速度快，就不能要求磁碟利用率高；要保證充分利用磁碟，節省空間，就無法注重讀取速度，所以要學會取捨。
閱讀筆記6 軟體架構設計
本書第九章主要介紹了概念架構的設計 概念架構的設計及其的重要，直至系統目標的設計思想，重 擇。首先，什麼是概念架構的設計 概念架構界定系統的高層元件 以及它們之間的關係。概念架構意在對系統進行適當分解 而不陷入細節。藉此，可以與管理人員 市場人員 使用者等非技術人員交流架構。概念架構規定了每個元件的...
《軟體架構設計》 閱讀筆記2
2.軟體架構設計方法 2.1 軟體架構為誰而設計 架構師應當為專案相關的不同角色而設計 架構師要為客戶負責，滿足他們的業務目標和約束條件。架構師要為使用者負責，滿足他們關心的功能需求和執行期質量屬性。架構師必須顧及處於協作分工 下游 的開發人員。架構師必須考慮 周邊 的管理人員，為他們進行分工管理 ...
軟體架構設計 架構師筆記，軟體架構設計
架構設計是分與合的藝術 通讀並總結了溫昱老師的 軟體架構設計 並有幸聽過李哲珠博士對架構設計的講解。對其讀後的自我領悟並提煉出核心內容分享出來，希望從思想高度上能提公升你對軟體架構設計的認知。架構設計 架構設計不等於框架設計，框架也可能有架構，所有的原子元件 被拆分的模組 都需要架構設計，所有元件可...