程序組織:

系統架構首先要以概括的形式對有關系統做一個綜述，如果沒有綜述，要想將成千上萬的局部圖片(或十多個單獨的類)拼為一副完整的圖畫是相當傷腦筋的，如果你不能將它們拼接起來，那么就無法理解你正在開發的那個類對系統有何貢獻！

如果在編寫一個類的時候，對這個類在系統中的角色沒有一個很清晰的構思，那么編寫這個類就是一件十分令人灰心喪氣的工作。需要對每個類進行慎重考慮！(功能->模塊->類->模塊->功能)

應該明確定義各個構造塊的責任。每個構造塊應該負責某一個區域的事情，并且對其它區域的事情知道的越少越好。通過使構造塊對其他構造塊的了解達到最小，你能將設計的信息局限于各個構造塊之內。

應該明確定義每個構造塊的通信規則，對于每個構造塊，架構應該描述它能夠直接使用哪些構造塊，能間接使用哪些構造塊，不能使用哪些構造塊。

主要的類:

架構應該詳細定義所用的主要的類。它應該指出每個主要的類的責任，以及該類如何與其它類交互(類的繼承體系/狀態轉換/對象持久化等描述)，根據80/20 規則對系統內部那些構成系統80%的行為的20%的類進行詳細說明。

數據設計:

架構應該描述所用到的主要文件和數據表設計。它應該描述曾經考慮過的其他方案，并說明選擇的理由(理由也寫一寫，特別是方案變更選取的時候)。

架構應該定義所用數據庫的高層組織結構和內容。指出與其他訪問同一數據的程序的可能交互方式，說明會創建哪些數據視圖等

業務規則:

如果架構依賴于詳細的業務規則，那么就應該詳細的描述這些規則，并描述這些規則對系統設計的影響。(比如客戶信息過時時間不超過30秒，在此情況下，架構就應該描述這條規則對架構采用的“保持客戶信息及時更新且同步”的方法的影響)

用戶界面設計:

用戶界面常在需求階段進行詳細說明.如果沒有就應該在軟件架構進行詳細說明。

架構應該模塊化，以便在替換為新用戶界面時不影響業務規則和程序的輸出部分。架構應該使我們很容易的做到:砍掉交互式的界面，插入一組命令行的類。

資源管理:

架構設計應該描述一份管理稀缺資源的計劃。稀缺資源包括數據庫連接/線程/句柄等。應該嘗試估算正常和極端情況下的資源使用量。各個類或者各個對象空間和時間的預算。

安全性:

緩沖區/處理非受信數據規則，加密，錯誤信息的細致程度，保存內存中的秘密數據，以及其他事項。

錯誤處理:

最后也是最重要的:

錯誤處理是進行糾正還是僅僅進行檢測？如果是糾正，那么程序可以嘗試從錯誤中恢復出來，如果僅僅是檢測，那么程序就可以像沒發生任何事情一樣繼續運行，也可也退出，但是無論哪種情況都應該通知用戶說檢測到了一個錯誤！

錯誤監測是主動的還是被動的？

程序如何傳播錯誤？(直接進行錯誤處理/等到所有處理完成，再通知說某個地方發現了錯誤!)

錯誤處理有什么約定?(架構應該有一套完整的錯誤消息約定)

如何處理異常?(架構應該規定代碼何時能夠拋出異常，在什么地方拋出異常，如何記錄(log)這些異常以及如何在文檔中描述這些異常)

每個類在驗證其輸入數據的有效性方面需要負何種責任？是每個類負責驗證自己數據的有效性還是有一組專門的類負責驗證整個系統數據的有效性？

容錯性:

檢查錯誤的時候倒退回去;

系統有一套輔助代碼，已備在主代碼出錯的時候使用;

表決算法;

系統使用不會對系統產生危害的虛假值來替代這個錯誤值;