關鍵的設計原則 在開始設計之前，思考一下關鍵的原則，將會幫助你創建一個最小花費、高可用性和擴展性的架構。 分離關註點，將應用劃分為在功能上儘可能不重覆的功能點。主要的參考因素就是最小化交互，高內聚、低耦合。但是，錯誤的分離功能邊界，可能會導致功能之間的高耦合性和複雜性， 職責單一，每一個組件或者是模 ...
關鍵的設計原則
在開始設計之前，思考一下關鍵的原則，將會幫助你創建一個最小花費、高可用性和擴展性的架構。
-
分離關註點，將應用劃分為在功能上儘可能不重覆的功能點。主要的參考因素就是最小化交互，高內聚、低耦合。但是，錯誤的分離功能邊界，可能會導致功能之間的高耦合性和複雜性，
-
職責單一，每一個組件或者是模塊應該只有一個職責或者是功能，功能要內聚。
-
最小知識原則，一個組件或者是對象不應該知道其他組件或者對象的內部實現細節。
-
不要重覆你自己，你只需要在一個地方描述目的。例如，特殊的功能只能在一個組件中實現，在其他的組件中不應該有副本。
-
最小化預先設計，只設計必須的內容。在一些情況，你可能需要預先設計一些內容。另外一些情況，尤其對於敏捷開發，你可以避免設計過度。如果你的應用需求是不清晰的，最好不要做大量的預先設計。
http://www.cnblogs.com/roucheng/p/wendang.html
當設計一個應用和系統的時候，軟體架構的目的是通過將設計分離到不同的關註點，來最小化複雜性。例如，用戶介面UI，業務處理Business Process，數據訪問Data Access就代表不同的關註點。在每個關註點內部，你設計的組件應該集中的內部實現，不應該和其他的組件混淆代碼。例如，UI處理組件不應該包括直接訪問數據源的代碼，相反，應該使用業務組件或者是數據訪問組建獲取數據。
但是，你還是要為你的應用做一個投入|產出決定。在某些情況，你可能需要簡化結構。例如，UI直接綁定到一個結果集。通常，也要從業務的角度考慮功能的邊界。下麵的這些高層次的原則將會幫助你從更廣的範圍上考慮影響設計、實現、部署、測試和維護系統的因素。
設計
在每一層保持設計模式的一致性。在一個邏輯層的內部，組件的設計對於特殊的功能應該保持一致性。
不要在應用中複製功能。只能在一個組件中提供指定的功能，這個功能不能在其他組件中複製。這將會保持組件的內聚性，而且如果功能需要修改的話，會變得很容易。
組合優先於繼承。無論在什麼地方，如果需要重用代碼的話，優先使用組合而不是繼承，因為繼承增加了父類和子類的依賴關係，限制了子類的重用，
為開發建立代碼風格和命名空間。建立統一的代碼風格，使用和組織有關係的有意義的命名空間。
在開發的過程中，使用QA來保證系統的質量。在開發的過程中，使用單元測試和其他QA技術，例如，依賴分析和靜態代碼分析。為組建和子系統定義清晰的行為和性能指標，使用自動化QA工具來保證不影響整個系統的質量。
應用分層
分離關註點。將應用分離為不同的功能，這些功能保持儘可能小的重疊。主要的好處是一個功能可以最小化和其他功能的依賴關係。另外，如果一個功能失敗了，不會導致其他功能的失敗，對於其他功能來說是獨立的。使得應用更容易理解和設計，簡化複雜系統的管理。
明確層之間是如何通信的。
使用抽象實現層之間的鬆散耦合。可以通過定義介面來實現。另外，還可以通過使用介面類型或者是基類定義常用的介面。
在同一層，不要混合不同類型的組件。例如，UI層不應該包含業務處理組件，相反，應該包含處理用戶輸入和處理用戶請求的組件。
在層和組件內部保持數據格式的一致性。混亂的數據格式，將會導致系統更難實現、擴展和維護。
組件、模塊和功能
一個組件和對象不應該依賴於其他組件的內部實現細節。
組件的功能不要超出範圍。例如，UI處理組件不應該包含數據訪問代碼，或者是試圖提供其他的功能。
理解組件之間是如何通信的。這需要理解應用一定要支持的部署方案。你一定要決定是否所有的組件都運行在同一個進程中？是否一定要支持跨越物理或者是進程邊界的通信？還是實現消息為基礎的介面？
為組件定義一個清晰的職責。
你還要考慮下麵的這些橫向的關註點：
日誌
認證
授權
異常管理
通信。選擇合適的協議，最小化網路的通信量，在網路上保護傳遞的敏感信息。
緩存。為了提高系統的性能和響應速度，需要確定什麼應該緩存？緩存在哪裡？設計緩存的時候，要考慮到web伺服器場和應用伺服器場的問題。
推薦：http://www.cnblogs.com/roucheng/p/chengxuyuan.html
