2023年10月24日 16:24:00
（節選自《軟體架構設計》書稿）
..如此看來，架構師應當為專案相關的不同角色而設計（如圖
5-2所示）：
l架構師要為客戶負責，滿足他們的業務目標和約束條件；
l架構師要為使用者負責，使他們關心的功能需求和執行期質量屬性得以滿足；
l架構師必須顧及處於協作分工"下游"的開發人員，
l架構師還必須考慮"周邊"的管理人員，為他們進行分工管理、協調控制、評估監控等工作提供清晰的基礎。
圖5-2
軟體架構師為誰而設計
一言以蔽之，軟體架構師必須做到內外兼顧、各層並重（如圖
5-3所示）。只有這樣，軟體架構才能和它"包含了關於如何構建軟體的一些最重要的設計決策"的"地位"相符。
補充三點：
●這個話題我在2006ibm開發者大會的預熱課堂上有過演講，說明了如何運用基於多檢視的架構設計方法應對上述問題。
運用rup 4+1檢視方法進行軟體架構設計
●其實，《軟體架構設計》一書講述的具體方法和4+1方法有所不同..例如，明確引入"質量屬性分析"活動來為效能、可伸縮性、可重用性、可擴充套件性等非功能需求制定相應的架構決策。書的第15章專門介紹質量屬性分析（例如如何運用"質量-場景-決策"表這種思維工具落實需求、制定設計決策等）。
軟體架構為誰而設計
節選自 軟體架構設計 書稿 如此看來，架構師應當為專案相關的不同角色而設計 如圖 5 2所示 l架構師要為客戶負責，滿足他們的業務目標和約束條件 l架構師要為使用者負責，使他們關心的功能需求和執行期質量屬性得以滿足 l架構師必須顧及處於協作分工 下游 的開發人員，l架構師還必須考慮 周邊 的管理人員...
軟體架構為誰而設計？
1.為使用者而設計。不僅包括功能性需求，也包括非功能性需求，例如效能 穩定性 健壯性等。2.為客戶而設計。使用者和客戶有時是不一樣的，可以這樣理解 客戶是出錢的，使用者是軟體產品的直接使用者。需要充分考慮客戶的特點。業務目標 時間需求 預算限制以及整合需求。3.為開發人員而設計。主要關注軟體的非功能...
為可變而設計
昨天review了乙份設計文件，資料模型設計的異常的 靈活 令我幾乎無法理解其中設計的奧妙.有感而發 記得以前我的 在接手乙個快爛掉的系統的時候，將該系統裡面的源 仔細閱讀後，砍掉了其中近1 3的 行，原因很簡單，原來系統設計了一大堆 靈活 的設計，使得系統看起來很強大，實際上由於各個人員水平參持不...