1、基本原則 在開始設計以前，考慮主要的設計原則將有助於找到架構的設計的「最佳方案」，下降成本和維護須要，提升系統的可用性和可擴展性。主要的設計原則以下： 關鍵點的分離：將應用程序分紅清楚的不一樣元素，使功能的重疊儘量的少。 單一責任原則：每個組件或模塊應該只負責惟一一個特定的功能。 最少知識原則：一個組件或對象應該不用知道其餘組件的內部實現細節，而只要按照彼此的約定調用便可。 不要重複本身：一個組件對應提供一個功能，一個功能也只應由一個組件提供。而不能將功能的實現分散到不少其餘的組件中去。 避免在前期作大量的設計：若是你的需求不是很清楚，或者有設計隨時間演變的可能，應當避免在項目前期作大量的設計工做。這一設計原則一般被叫作「BDUF」。 多用組合少用繼承：在儘量的狀況下，使用組合的方式來重用功能，而不使用繼承的方式。由於繼承增長了父子類之間的依賴關係，限制了子類的重用。 2、設計要點 在設計軟件或系統時，軟件架構的目標就是經過將設計分割爲不一樣的關注領域來下降其複雜性。例如，用戶接口、業務進程和數據訪問都可視爲不一樣的關注領域。在每一個領域內部，組件應專一於其特定的領域，而不該該混合其餘領域的代碼。例如，UI進程組件不該該包括直接訪問數據源的代碼，而應該使用其餘的業務組件或數據訪問組件檢索數據。 下面列出了設置應用程序的指導方針： 避免在前期作全部的設計：若是系統需求不清楚或存在設計演變的可能，在前期不去作一個完整的設計應該是一個好主意。在項目進程中演化設計應該是一個恰當的方法。 分割關注領域：將應用程序分紅清楚的不一樣元素，使功能的重疊儘量的少。這種方法的好處是一個特徵或功能獨立於其餘的特徵或功能，能夠實現最優。還有，若是一個特徵失敗了，不會致使其餘的特徵也失敗，它們之間彼此獨立運行，互不影響。這種方法也有助於應用程序的設計和理解，便於複雜的互相依賴的系統的管理。 每一個組件或模塊應有單一的責任：每個組件或模塊應該負責實現特定的特徵或功能。這可使組件實現內聚且更容易優化和變動。 一個組件或對象不該該依賴其餘組件或對象的內部細節：組件或對象調用其餘組件或對象的方法，這些被調用的方法應該說明如何去使用它。若是須要，將這些內容放在子組件或其餘獨立的組件中。這將有助於開發一個具備可維護性和適應性的應用程序。 在一個應用程序內部不要複製功能：應該只有一個組件提供特定的功能——這個功能不該該在其餘的組件中出現。在一個應用程序中複製功能會使功能的變動很難維護，削弱了程序的條理性，引入了潛在的矛盾。 肯定應用程序組件的組成部分：實現這一點的最好方法是肯定符合你狀況的模式，檢查這些模式所使用的組件的類型。例如，一個小型的應用程序可能不須要一個業務工做流或者UI進程組件。 組織不一樣類型的組件到各自的邏輯層：在一開始，肯定不一樣的關注領域，而後組織相互關聯組件到合適的邏輯層中。 保持層間設計模式的一致性：在一個邏輯層中，組件的設計對於一類特定的功能應該是一向的，有延續性的。例如，若是你選擇使用表數據網關的模式建立對象，你就不該該再使用其餘的方式來訪問數據和初始化業務對象。 在同一邏輯層中不該混合不一樣類型的組件：例如，UI層不該該包含業務進程組件，而應該包括處理用戶輸入和處理用戶請求的組件。 肯定哪類分層要強制執行：在一個嚴格的分層系統中，A層中的組件不能調用C層中的組件，它應老是調用層B中的組件。而在一個相對寬鬆的分層系統中，一個層中的組件能夠調用其下層中的組件，而不僅是正下層中的組件。在任何狀況下，都應該避免對上層的調用和依賴。 抽象實現層間的鬆散耦合經過定義接口，層內的組件間能夠以一種共知的方式彼此進行請求和響應，這樣的實現相對比較靈活。另外，你也能夠用接口或抽象類來定義公共的接口或者抽取公共的部分（依賴倒置）。 一個組件不要承載太多的功能：例如，一個UI進程組件不該該包括數據訪問代碼。一種常見的違反模式的狀況叫作Blob（一團），在這種狀況下，基類提供了過多的功能。一個「團」對象一般有不少函數和屬性用來提供混合了日誌和異常處理的業務功能。因爲要處理子功能的各類變體，作複雜的初始化，這類對象一般很是龐大。最終結果是，這種的設計很容易產生錯誤，並且很難維護。 清楚組件間是如何通訊的：這首先須要瞭解你的應用程序是如何部署的。須要明確的是，組件間的通訊是否須要跨越物理邊界或跨進程，全部組件是否運行在統一進程當中。 多用組合少用繼承：在儘量的狀況下，使用組合的方式來重用功能，而不使用繼承的方式。由於繼承增長了父子類之間的依賴關係，限制了子類的重用。這也減小了繼承的層級，避免了去處理複雜的層級關係。 保持層內或組件內數據格式的一致性：混亂的數據格式會使程序很難運行、擴展和維護。每次你都須要在不一樣格式間進行轉換，執行轉換的代碼。這樣減低了性能，並且沒有必要。 儘量的將交叉（橫切）代碼從業務邏輯中抽象出來：交叉（橫切）代碼一般涉及到安全性、通訊和操做管理（例如，日誌和檢測）。將這些代碼混合到業務邏輯中會致使程序擴展和維護上的困難。修改這些交叉（橫切）代碼會牽聯到全部混合了它們的業務邏輯代碼的修改。能夠考慮使用框架來實現交叉（橫切）的集中處理。 命名習慣的統一：看看團隊、組織裏是否創建了相關的命名規定，若是沒有，你應該創建一個公用的命名標準。由此而來的代碼的一致性會使團隊成員檢查代碼更容易。這樣也更易維護。 創建異常處理的標準：例如，應該老是在層的邊界捕獲異常，不該該在層內捕獲異常，除非你能夠在層內處理它，也不該該用異常來實現業務邏輯。該標準還應包括錯誤提示、記錄日誌的策略和對異常的檢測 3、架構框架 下面的表格列出了你在設計架構時應該考慮的主要方面。經過這些關鍵的問題了解一般會犯錯的地方。這個章節爲這些不一樣的方面提供了指導。 表格1架構框架
認證和受權數據庫
缺乏跨信任邊界的認證
缺乏跨信任邊界的受權
鬆散或不適當的受權設計模式
緩存緩存
數據緩存反覆無常
緩存敏感數據
選擇了錯誤的緩存方式安全
通訊架構
選擇了錯誤的傳輸協議
多餘的跨物理和進程邊界的通訊
沒有有效的保護敏感數據併發
組合框架
彼此協做的應用模塊之間相互依賴使開發、測試和維護變得很困難。
模塊間的依賴變動強制代碼從新編譯和模塊的從新部署
頑固的代碼依賴使動態的UI佈局和更新變得很困難
頑固的代碼依賴使模塊的動態加載變得很困難函數
併發和事務處理佈局
沒有保護對靜態數據的併發訪問
死鎖致使不適當的鎖定
沒有選擇適當的併發處理模式
長期保持對數據的鎖定
不恰當的使用互鎖性能
配置管理
缺乏或存在錯誤的配置信息
沒有對敏感的配置信息採起保護措施
無限制的對配置信息的訪問
連接和聚合
錯誤的功能分組
關注點的分離不清楚
層間的連接過於緊密
數據訪問
對總用戶的沒必要要的驗證和受權
多餘的對數據庫的訪問
業務邏輯摻雜數據訪問代碼
異常管理
處於不穩定狀態
向最終用戶暴露敏感信息
使用異常控制程序流程
沒有記錄有關異常足夠的細節
分層
對組件進行了錯誤的分層
沒有遵照分層和從屬劃分的規則
沒有考慮層間的物理分佈
日誌和檢測
缺乏日誌和檢測
日誌和檢測太過細緻
沒有將日誌和檢測作成運行時可配置的
沒有阻止和處理日誌記錄失敗的發生
沒有對關鍵的業務進行日誌記錄
狀態管理：
使用了錯誤的狀態存儲
沒有考慮序列化的須要
沒有在須要的時候保持狀態
結構：
針對方案選擇了錯誤的結構
建立了一個過於複雜的結構，而這是沒有必要的
沒有考慮部署方案
用戶體驗：
沒有遵循發佈的指導方針
沒有考慮易用性
對不相關的函數建立重載接口
驗證：
缺乏跨信任邊界的驗證
沒有對範圍、類型、格式和長度進行有效的驗證
沒有重用驗證邏輯
工做流：沒有考慮管理的需求錯誤選擇工做流模式沒有考慮異常狀態及對它們的處理