1.
為使用者而設計。
不僅包括功能性需求，也包括非功能性需求，例如效能、穩定性、健壯性等。
2.為客戶而設計。
使用者和客戶有時是不一樣的，可以這樣理解：客戶是出錢的，使用者是軟體產品的直接使用者。
需要充分考慮客戶的特點。業務目標、時間需求、預算限制以及整合需求。
3.為開發人員而設計。
主要關注軟體的非功能性需求。
4.為管理人員設計。
為專案經理制定專案計畫、管理專案分工和考核專案進度提供參考。
什麼是軟體架構檢視？
乙個架構檢視是對於從某一視角或某一點上看到的系統所做的簡化描述，描述中涵蓋了系統中某一特定方面，而省略了與此方面無關的實體。
軟體架構檢視出現的原因：分治思想。
一方面，出於交流的考慮，架構師如果不採用檢視的方式，那麼和不同部分的人員交流就會產生困難。
另一方面，軟體架構是乙個非常複雜的事情，架構中，會牽扯到很多概念和技術，而利於軟體架構檢視的方法，使得問題得以清晰化和簡單化。
傳統意義上，架構可以分為物理架構和邏輯架構兩部分。
軟體的邏輯架構規定了軟體系統由哪些邏輯元素組成以及這些邏輯元素之間的關係。
軟體的邏輯架構的任務：
1.識別功能。
2.規劃功能塊的介面。
3.明確功能之間的使用關係和使用機制。
邏輯架構中關於職責劃分的決策，體現為層、子系統和模組等的劃分決定，從靜態的視角為詳細設計和程式設計實現提供實際的指導，有了分解就必須產生協作，邏輯架構還規定了不同邏輯單元之間的互動介面和互動機制。
一般的互動機制包括方法呼叫、基於rmi的遠端方法呼叫和訊息機制等。
軟體的物理架構規定了元件系統的物理元素，這些物理元素之間的關係，以及它們部署到硬體上的策略。物理架構可以反映出軟體系統動態執行時的組織情況。
物理架構規定了軟體系統如何使用程序和執行緒完成期望的併發處理，程序執行緒這些主動物件會呼叫哪些被動物件參與處理，互動機制是怎樣的等，從而為詳細設計和程式設計提供了工作目標的動態檢視。
軟體架構為誰而設計
節選自 軟體架構設計 書稿 如此看來，架構師應當為專案相關的不同角色而設計 如圖 5 2所示 l架構師要為客戶負責，滿足他們的業務目標和約束條件 l架構師要為使用者負責，使他們關心的功能需求和執行期質量屬性得以滿足 l架構師必須顧及處於協作分工 下游 的開發人員，l架構師還必須考慮 周邊 的管理人員...
軟體架構為誰而設計
2006年10月24日 16 24 00 節選自 軟體架構設計 書稿 如此看來，架構師應當為專案相關的不同角色而設計 如圖 5 2所示 l架構師要為客戶負責，滿足他們的業務目標和約束條件 l架構師要為使用者負責，使他們關心的功能需求和執行期質量屬性得以滿足 l架構師必須顧及處於協作分工 下游 的開發...
為可變而設計
昨天review了乙份設計文件，資料模型設計的異常的 靈活 令我幾乎無法理解其中設計的奧妙.有感而發 記得以前我的 在接手乙個快爛掉的系統的時候，將該系統裡面的源 仔細閱讀後，砍掉了其中近1 3的 行，原因很簡單，原來系統設計了一大堆 靈活 的設計，使得系統看起來很強大，實際上由於各個人員水平參持不...