軟件架構（software archivtecture）是軟件設計的高層部分，是用于支撐更細節的設計的框架。架構也稱為“系統架構/system architecture”、“高層設計/high-level design”或“頂層設計/top-level design”。
為什么要把架構作為前期準備呢？
因為架構的質量決定了系統的“概念完整性”。后者繼而決定了系統的最終質量。一個經過慎重考慮的架構為“從頂層到底層維護系統的概念完整性”提供了必備的結構和體系，它為程序員提供了指引——其細節程度與程序員的技能和手邊的工作相配，它將工作分為幾個部分，使得多個開發者或者多個開發團隊可以獨立工作。
架構的典型組成部分
很多組成部分是優秀的系統架構所共有的。
1.程序組織
系統架構首先要以概括的形式對有關系統做一個綜述。
如果對某個類在系統中的角色沒有一個清晰的構思，那么編寫這個類就是一件令人灰心喪氣的工作。描述其他組織結構，才能說明架構最后選定的這種關系組織結構的緣由并且表明各個類都是經過慎重考慮的。
架構應該定義程序的主要構造塊（building blocks）。根據程序規模不同，各個構造塊可能是單個類，也可能是由許多類組成的一個子系統。每個構造塊無論是一個類還是一組協同工作的類和子程序，它們共同實現一種高層功能，諸如用戶交互、顯示web頁面、解釋命令、封裝業務規則、訪問數據等等。每條列在需求中的功能特性（feature）都至少應該有一個構造塊覆蓋它。如果兩個或多個構造塊聲稱實現同一項功能，那么它們就應該相互配合而不會沖突。
應該明確定義各個構造塊的責任。每個構造塊應該負責某一個區域的事情，并且對其他構造塊負責的區域知道的越少越好。通過使各個構造塊對其他構造塊的了解達到最小，你能將設計的信息局限于各個構造塊之內。
應該明確定義每個構造塊的通信規則。對于每個構造塊，架構應該描述他能直接使用哪些構造塊，能間接使用哪些構造塊，不能使用哪些構造塊。
2.主要的類
架構應該詳細定義所用的主要的類。
3.數據設計
架構應該描述所用到的主要文件和數據表的設計。
4.業務規則
如果架構依賴于特定的業務規則，那么它就應該詳細描述這些規則，并描述這些規則對系統設計的影響。
5.用戶界面設計
用戶界面常常在需求階段進行詳細說明。如果沒有，就應該在軟件架構中進行詳細說明。
架構應該模塊化，以便在替換為新用戶界面時不影響業務規則和程序的輸出部分。
6.資源管理
架構應該描述一份管理稀缺資源的計劃。稀缺資源包括數據庫連接、線程、句柄（handle）等。
7.安全性
架構應該描述實現設計層面和代碼層面的安全性的方法。如果先前尚未建立威脅模型（threat model），那么就應該在架構階段建立威脅模型。
8.性能
如果需要關注性能，就應該在需求中詳細定義性能目標。
9.可伸縮性
可伸縮性是指系統增長以滿足未來需求的能力。架構應該描述系統如何應對用戶數量、服務器數量、網絡節點數量、數據庫記錄數、數據庫記錄長度、交易量等的增長。如果預計系統不會增長，而且可伸縮性不是問題，那么架構應該明確地列出這一假設。
10.互用性
如果預計這個系統會與其他軟件或硬件共享數據或資源，架構應該描述如何完成這一任務。
11.國際化/本地化（Internationalization/Localization）
“國際化”是一項“準備讓程序支持多個locales(地域/文化)”的技術活動。
12.輸入輸出（Input/Output）
輸入輸出（I/O）是架構中值得注意的另一個領域。
13.錯誤處理（Error Processing）
錯誤處理已被證實為現代計算機科學中最棘手的問題之一，你不能武斷地處理它。
14.容錯性（Fault Tolerance）
架構還應該詳細定義所期望的容錯種類。
15.架構的可行性（Architectural Feasibility）
設計師多半會關注系統的各種能力，例如是否達到性能目標，能夠在有限的資源下運轉，實現環境（運行環境）是否有足夠的支持。架構應該論證系統技術的可行性。
16.過度工程（Overengineering）
詳細定義一種過度工程（裕度工程）的方法尤其重要，因為許多程序員會出于專業自豪感，對自己編寫的類做過度工程。通常在架構中明確的設立期望目標，就能避免出現“某些類異常健壯，而其他類勉強夠健壯”的現象。
17.關于“買”還是“造”的決策（Buy-vs-Build Decision）
18.關于復用的決策（Reuse Decisions）
19.變更策略（Change Strategy）
20.架構的總體質量（General Architectural Quality）
架構應該是帶有少許特別附加物的精煉且完整的概念體系。
