（說明：這些知識沒有統一的標準，以下內容緊供參考，歡迎您能閱後改進）
一、 架構設計文檔：
需求分析完成約80％的時候開始進行。
目的目標：架構應儘可能簡化，架構文檔應簡單、簡短，清晰而不雜亂，解決方案自然。
先定義上層的主要子系統，應該描述各子系統的任務，並提供每個子系統中各模塊或對象類的的初步列表。
應該描述不同子系統間相互通信的方式，而一個良好的架構應該將子系統間的通信關係降到最低。
成功架構的一個重要特色，在於標明最可能變更的領域，應當列出程序中最可能變更的部分，說明架構的其他部分如何應變。
複用分析、外購：縮短軟件開發週期、降低成本的有效方案未必是自行開發軟件，可以對現有軟件進行復用或進行外購。應考慮其對架構的影響。
除了系統組織的問題，架構應重點考慮對於細節全面影響的設計決策，深入這些決策領域：
外部軟件接口（兼容性、通信方式、傳遞數據結構）、用戶接口（用戶接口 和系統層次劃分）、數據庫組織和內容、非數據庫信息、關鍵算法、內存管理（配置策略）、並行性、安全性、可移植性、網絡多人操作、錯誤處理。
要保證需求的可追蹤性，即保證每個需求功能都有相應模塊去實現。
架構不能只依據靜態的系統目標來設計，也應當考慮動態的開發過程，如人力資源的情況，進度要求的情況，開發環境的滿足情況。架構必須支持階段性規劃，應該能 夠提供階段性規劃中如何開發與完成的方式。
不應該依賴無法獨立運行的子系統架構。
將系統各部分的、依賴關係找出來，形成一套開發計劃。
建議參考架構設計文檔（模板），取長補短。
二、 軟件開發源代碼組織：
0）版本管理：SVN，CVS。。。
1） 開發可管理性：便於人員分工（模塊獨立性、開發工作的負載均衡、進度安排優化、預防人員流動對開發的影響）、利於配置管理、大小的合理性與適度複雜性；
2） 可維護性：與運行可管理性不同；
3） 可擴充性：系統方案的升級、擴容、擴充性能；
4） 可移植性：不同客戶端、應用服務器、數據庫管理系統；
5） 需求的符合性：從源代碼的組織結構看需求的符合型主要考慮針對用戶需求可能的變化的軟件代碼及構架的最小冗餘（同時又要使得系統具有一定的可擴展性）。
（每項詳情請自行完善）
三、 程序運行設計：
1） 需求的符合性：正確性、完整性；功能性需求、非功能性需求；
2） 總體性能（內存管理、數據庫組織和內容、非數據庫信息、任務並行性、網絡多人操作、關鍵算法、與網絡、硬件和其他系統接口對性能的影響）；
3） 運行可管理性：便於控制系統運行、監視系統狀態、錯誤處理；模塊間通信的簡單性；與可維護性不同；
4） 與其他系統接口兼容性；
5） 與網絡、硬件接口兼容性及性能；
6） 系統安全性；
7） 系統可靠性；
8） 業務流程的可調整性；
9） 業務信息的可調整性；
10） 使用方便性；
11） 架構樣式的一致性；
注：運行時負載均衡可以從系統性能、系統可靠性方面考慮。
（每項詳情請自行完善）
四、 軟件架構有關的一些基本概念：
1、模塊（module）
2、組件（component）
3、 模式（pattern）：例如，架構模式、分析模式、設計模式和代碼模式或實施模式。
4、架構模式（architectural pattern）：表示軟件系統的基本結構組織方案。它提供了一組預定義的子系統、指定它們的職責，並且包括用於組織其間關係的規則和指導。
5、 層（layer）
6、系統分層的幾種常用方法：
1） 常用三層服務：用戶層、業務邏輯層、數據層；
2） 多層結構的技術組成模型：表現層、中間層、數據層；
3） 網絡系統常用三層結構：核心層、匯聚層和接入層；
4） RUP典型分層方法：應用層、專業業務層、中間件層、系統軟件層；
5） 基於Java的B/S模式系統結構：瀏覽器端、服務器端、請求接收層、請求處理層；
6） 某六層結構：功能層（用戶界面）、模塊層、組裝層（軟件總線）、服務層（數據處理）、數據層、核心層；
7、 架構（Architecture）
8、架構的描述方式：“4＋1”視圖 （用例視圖、設計視圖、實現視圖、過程視圖、配置視圖）是一個被廣爲使用的架構描述的模型；RUP過程的架構描述模板在“4＋1”視圖的基礎上增加了可選的數據視圖（從永久性數據存儲方面來對系統進行說明）；HP公司的軟件描述模板也是基於“4＋1”視圖。
9、結構：軟件架構是多種結構的體現，結構是系統架構從不同角度觀察所產生的視圖。就像建築物的結構會隨着觀察動機和出發點的不同而有多種含義一樣，軟件架構也表現爲多種結構。常見的軟件結構 有：模塊結構、邏輯或概念結構、進程或協調結構、物理結構、使用結構、調用結構、數據流、控制流、類結構等等。
五、 系統架構基礎：
1，操作系統：。。。
2，數據庫系統：。。。
3，網絡基礎知識：。。。
4，系統性能：。
（以上每一項都需要展開展開再展開。。。還要嵌套。。。）