《微軟應用架構指南 (第2版)》 [作者] (美) Patterns & Practices[譯者] (中) 朱曄 高翔 王敏[出版] 電子工業出版社[版次] 2010年11月 第1版[印次] 2010年11月 第1次 印刷[定價] 69.00元 【前言】 (P001) 開發人員和方案解決架構師通常 ...
《微軟應用架構指南 (第2版)》
========== ========== ==========
[作者] (美) Patterns & Practices
[譯者] (中) 朱曄 高翔 王敏
[出版] 電子工業出版社
[版次] 2010年11月 第1版
[印次] 2010年11月 第1次 印刷
[定價] 69.00元
========== ========== ==========
【前言】
(P001)
開發人員和方案解決架構師通常是游走在“黃金方案”和“即時方案”之間。
架構就是利用現有的技術和工具來創造儘可能多的商業價值，一方面關註現有業務所提出的需求和限制，另一方面著眼於未來通過可伸縮性、靈活性以及可維護性等方面最大化價值。
【第01章】 【什麼是軟體架構】
(P003)
軟體應用架構是一個結構化解決方案，這種結構化解決方案一方面可以滿足所有技術和運營需求，另一方面可以滿足常見的質量特性 (quality attribute) 要求，例如性能、安全以及可管理性等。它涵蓋了受多重因素影響的一系列決策，每種決策對質量、性能、可維護性及應用程式總體的成功都有相當大的影響。
(P004)
一個失敗的架構帶來的風險包括軟體不穩定、不能支持既有或將來的業務需求、或難以在生產環境中部署和管理。
系統在設計的時候需要考慮用戶、系統 (IT基礎結構) 和業務。對於每一個方面，您都應該列出關鍵應用場景，並找出重要質量特性 (例如可靠性或可伸縮性) 和令人滿意或不滿意的關鍵點。如果可能的話，在每一個需要考慮的方面，都建立衡量得失的標準。
架構關註構成應用程式的主要元素和組件的使用和它們之間的交互。而設計則主要關註與數據結構和演算法的選擇，以及組件細節的實現。
架構師必須考慮設計決策導致的總體效果，以及與生俱來的權衡，包括眾多質量屬性之間的權衡和用戶、系統和業務需求之間的權衡。
要記住，架構應該 :
1. 展示系統的結構但是隱藏實現細節；
2. 意識到所有用例和應用場景；
3. 力求顧及各參與者的需求；
4. 處理功能和質量需求；
(P005)
使用那些在大量解決方案中經過驗證的，可以解決常見問題的模式。
不要對架構進行過度設計，尤其是不要針對那些無法驗證的事情做出任何假設，我們只需要在設計的過程中為將來可能的變化留出餘地即可。
【第02章】 【軟體架構的關鍵原則】
(P007)
架構註重把組件進行組織以支持特定功能。
(P008)
在設計應用程式或系統的時候，軟體架構師的目標是通過把設計分割為不同的關註點來儘量減少複雜度。
對於每一個點，我們設計的組件就關註此特定點，不應混合其他關註點的代碼。
(P009)
關註點分離 —— 把您的應用程式分解為儘可能不發生功能重疊的不同特性。這樣做最大的好處是某個特性或功能可以獨立於其他特性或功能進行優化。
明確層之間如何通信 —— 如果允許應用程式中的層和其他所有層進行通信或依賴，可能會導致解決方案更難理解和管理，需要考慮清楚層間的依賴和層與層間數據的流動。
組件或對象不應該依賴其他組件或對象的內部細節 —— 每一個組件或對象應該只調用另一個組件或對象的一個方法，並且這個方法知道如何處理請求，如何把它轉發到合適的子組件或其他組件，這有助於創建可維護性和可適應性更高的應用程式。
(P010)
確保橫切代碼儘可能從應用程式業務邏輯中抽象出來 —— 橫切代碼指的是有關於安全、通信或諸如日誌和指示器等運營管理的代碼。
(P011)
每一個應用程式設計都必須考慮安全性和性能，但不是每一個設計都需要考慮互操作性和可伸縮性。
【第03章】 【架構模式和風格】
(P013)
架構風格 (architectural style) 有時候又被稱作架構模式，它是一組原則 —— 為一族 (a family of) 系統提供抽象框架的粗粒度的模式。
理解架構風格有很多好處，最大的好處在於它提供了通用表達方式，還為技術無關的討論提供了機會，能讓我們在不涉及具體細節的情況下針對模式和原則進行高層的討論。
(P014)
軟體系統的架構幾乎都不會局限於單個架構風格，而通常是使用架構風格的組合來構成完整的系統。
(P016)
最簡單的 客戶端 / 服務端 系統包含了可以由多個客戶端直接訪問的服務端應用程式，也稱作兩層架構風格。
(P017)
可以使用諸如依賴註入 (Dependency Injection) 模式或者是服務定位器 (Service Locator) 之類的設計模式來管理組件之間的依賴關係，並且提供鬆散的耦合和重用。
(P018)
為應用程式進行正確的分層可以幫助您有效地分離關註點，從而增進靈活性和可維護性。
分層架構風格通常稱為重用的倒金字塔 (inverted pyramid of reuse) ，每一層對直接下層的職責和抽象進行聚合。對於嚴格的分層結構來說，層中的組件只能和相同層或直接下層中的組件進行交互，而較鬆散的分層結構則允許層中的組件和相同層以及任何下屬層中的組件進行交互。
應用程式的層可能放在相同的物理機器上 (相同物理層) 或是分佈在獨立的機器上 (N 物理層)，並且每一層中的組件通過明確定義的介面來和其他層中的組件進行通信。
可重用 —— 下層對上層沒有依賴，這也就使得下層可以在其他應用場景中被重用。
松耦合 —— 層之間的通信基於抽象和事件，這也就提供了層和層之間的松耦合。
(P019)
性能 —— 通過把邏輯層分佈到多個物理層中可以提高擴展性、容錯性 (fault tolerance) 和性能。
(P020)
消息匯流排架構通常使用消息路由或 發佈 / 訂閱 模式，並且通常使用諸如消息隊列的消息系統來實現。
複雜的處理邏輯 —— 可以通過整合一組小的操作來構成複雜操作，每一個小操作都完成特定任務，多個小操作組合成一個多步操作。
(P021)
N 層或三層是一種架構部署風格，它以一種和分層風格很相似的方式把功能分割為不同的片段，只不過每個片段作為一個物理層，將會分佈在物理上分離的電腦上。它從面向組件的方式發展而來，通常使用特定於某個平臺的方式而不是基於消息的方式來通信。
N 層應用架構的主要特征是 : 應用程式功能分離，服務組件、組件的分散式部署，提供增強的可伸縮性、可用性、可管理性及充分利用資源。除了直屬上層和下層之外，每一個物理層完全獨立於其他的層。n 層只知道如何處理 n+1 層的請求，如何把請求返回給 n-1 層 (如果有的話) ，以及如何處理請求的結果。一般層之間的通信是非同步的，以便更好地支持可伸縮性。
N 層架構通常至少有三個分離的邏輯部分，每一部分都部署於獨立的物理伺服器上，每一部分負責特定的功能。在使用分層設計方式的時候，如果有超過一個服務或應用程式使用邏輯層的功能就把它部署為物理層。
N 層 / 三層 架構風格的主要優勢在於 :
1. 可維護性 —— 由於每一層相對於其他層來說是獨立的，更新或修改部分都不會對整個應用程式發生影響；
2. 可伸縮性 —— 由於物理層基於邏輯層來部署，橫向擴展應用程式就變得相當簡單；
3. 靈活性 —— 由於每一層都獨立管理和擴展，也就增加了靈活性；
4. 可用性 —— 應用程式可以使用易於擴展的組件來形成模塊化的系統，增加了可用性；
(P022)
通過使用一系列的協議和數據格式來交流信息， SOA 架構風格可以把業務處理包裝成可互操作的服務，客戶端和其他服務可以訪問運行於相同物理層的本地服務，也可以通過連接的網路訪問遠程服務。
【第04章】 【架構和設計的方法】
(P026)
架構過程應該是迭代和增量的方式。
(P027)
在架構和設計的過程中，用例 (use case) 描述的是一組交互行為，它可以是系統和一個或多個因素 (用戶或另外一個系統) 之間的交互。而應用場景 (scenario) 描述的是廣義上用戶和系統的交互，這種交互並不通過用例的路徑。
(P028)
架構風格是一組原則。您可以把它認為是一個粗粒度的模式，它可以為一族系統提供抽象框架。每一個風格定義了一組規則，它指定構成系統的組件類型、組件之間的關係、組裝方式的約束以及組裝時使用的一些假想。
架構風格可以提高系統的分層程度，並且通過為經常發生的問題提供解決方案來提升設計的重用性。
應用程式往往使用多個風格的組合。
(P029)
在選擇您設計中會使用的技術的時候，您需要考慮哪些技術可以支持所選的架構風格、應用程式類型及應用程式的關鍵質量特性。
是否可以畫出架構很重要。
【第05章】 【分層應用程式指導原則】
(P039)
層關註的是組件和功能的邏輯劃分 (logical division) ，不考慮組件的物理位置。層可以位於不同的物理層也可以屬於相同的物理層。
我們需要理解邏輯層 (layer) 和物理層 (tier) 的區別。邏輯層描述的是應用程式中功能和組件的邏輯分組；而物理層 (Tier) 描述的是把功能和組件從物理上分佈到獨立伺服器、電腦、網路或遠程位置。
把超過一個邏輯層放在同一個物理機器上 (一個物理層) 很常見。
層有助於區分組件進行的不同類型的任務，這樣使得我們的設計可以很容易支持組件重用。
每一個邏輯層包含許多獨立的組件類型並分組成子層，每一個子層執行特定類型的任務。
把應用程式分割為具有不同角色和不同功能的層不僅有助於最大化代碼的可維護性，而且能通過改變部署方式最優化應用程式的工作方式，以及提供一個清晰的描述展示各個位置上必須實現的技術或設計決策。
從最高級的和最抽象的角度來說，任何系統在邏輯架構層面都可以看作是把一組相互協作的組件分組成邏輯層。
(P040)
表現層 —— 這個層包含面向用戶的功能，負責管理用戶和系統之間的交互，通常還包含一些組件，我們可以利用這些組件來訪問封裝在業務層的核心業務邏輯。
業務層 —— 這個層實現了系統的核心功能並且封裝了相關業務邏輯。它通常由一些組件構成，一些組件可能會暴露服務介面供其他調用者使用。
數據層 —— 這一層提供針對寄存在系統邊界內的或者由其他聯網系統暴露的數據的訪問，這種訪問可能是通過服務的方式進行的。
從較高的層面來看，基於服務的解決方案可以看作是由多個服務構成，每一個服務通過傳遞消息和其他服務進行通信。從概念上來說，服務可以看作是整個解決方案的一些組件。然而，在內部每一個服務和其他任何應用程式一樣都由軟體組件構成，並且這些組件可以在邏輯上分組為表現層、業務層和數據層。
(P041)
如果應用程式必須為其他應用程式提供服務，或者要實現一些直接提供給客戶端的特性，通常的方式就是使用服務層來暴露應用程式的業務功能。
(P042)
在設計應用程式的時候，第一件事情就是關註最高層次的抽象，也就是功能的分層，然後必須為每一層 (取決於設計的應用程式的類型) 定義公共介面。定義了層和介面之後，還必須決定應用程式的部署方式，最後選擇要使用的通信協議，用於邏輯層和物理層之間的交互。
使用分層的方式可以改善應用程式的可維護性，並且在需要改善性能的時候可以更方便地進行橫向擴展 (scale out) 。
確定分層策略中至關重要的第一步就是為應用程式確定合適的分層粒度。
(P043)
為了保持靈活性，總是需要確保層之間的交互是松耦合的。
採用分層方式會增加一些複雜度，並且可能會增加初始的開發時間，但是如果正確實施的話，會極大提高應用程式的可維護性、可擴展性和靈活性。必須在重用性、松耦合和影響性能、增加複雜度之間進行權衡選擇。總體上來說，分層設計提供的靈活性和可維護性的優勢遠遠超過了使用不分層的緊密耦合設計帶來微弱的性能上的提升。
業務應用程式中最常見的作法是把表現、服務、業務和數據訪問功能分成獨立的層。一些應用程式還引入報表、管理或基礎結構層。
如果需要增加層的話請慎重考慮，如果對相關聯的組件進行邏輯分組不能明確增加應用程式可維護性、可伸縮性或靈活性的話，就不應該增加層。
只有在必要的時候才應該跨越獨立的物理層來分佈邏輯層和組件。
(P044)
找出應用程式中所有橫切關註點很重要，儘可能為每一個關註點設計獨立的組件。這種方式可以幫助您獲得更好的重用性和維護性。
在為層定義介面的時候，首要的目標是實現層之間的松耦合。也就是說層不應該暴露內部細節讓其他層進行依賴。而是應該設計層的介面，通過提供能夠隱藏層中組件細節的公共介面來最小化依賴。這種隱藏稱作抽象 (abstraction) ，並且有很多不同的方式來實現。
(P045)
一個層不會依賴於另外一個層，層都依賴於公共介面。
【第06章】 【表現層指導原則】
(P047)
表現層包含的組件可以實現和顯示用戶界面並且管理用戶交互。它包含一些用於用戶輸入和顯示的控制項及一些組織用戶交互的組件。
(P049)
緩存是用來提高應用程式性能和 UI 響應速度最好的方法之一。
(P050)
對長時間運行的行為，要為用戶提供進度反饋。考慮允許用戶取消長時間運行的操作。
(P051)
除非捕獲的異常能處理，否則別隨便使用自定義的異常，並且不要使用異常來控制應用程式的邏輯流程。
(P052)
輸入驗證應該由表現層來處理，而業務規則驗證應該由業務層來處理。
如果您的業務層和表現層在物理上是分離的，業務規則的驗證邏輯還應該在表現層也實現一份，以提高可用性和響應速度。
(P055)
對於 ASP.NET ，要小心地使用 ViewState ，因為它可能會在每一次往返中增加數據量，降低應用程式的性能。應考慮配置頁面使用只讀會話，甚至可以的話，考慮不使用會話。
【第07章】 【業務層指導原則】
(P060)
要最大化重用，業務邏輯組件不應該包含任何只能用於特定用例或應用場景的行為或應用程式邏輯。
在設計業務層的時候，軟體架構師的目標是通過把任務分成不同的關註點來最小化複雜度。
對於每一個點，您設計的組件都應該關註在特定點上，並且不應該包含和其他關註點相關的代碼。
應該儘可能使用獨立的業務層來提高應用程式的可維護性。
如果業務層會同時被表現層和外部應用程式使用，就可以選擇通過服務來展示業務層。
(P061)
為業務層創建介面的時候使用抽象原則最小化耦合。抽象的技術包括使用公共對象介面，通用介面定義，抽象基類或消息。
為業務層設計有效的身份驗證策略對應用程式的安全性和可靠性很重要。
為業務層設計有效的授權策略對應用程式的安全和可靠性很重要。
(P062)
對於角色，應考慮儘可能讓粒度變小以減少需要的許可權組合數量。
為業務層設計合適的緩存策略對於應用程式的性能和響應速度很重要。
只緩存非常必要的數據。
在為業務層設計組件的時候，應確保它們是高內聚的，並且層間是低耦合的。這樣就可以提高應用程式的可擴展性。
(P063)
為業務層設計有效的異常管理解決方案對應用程式的安全性和可靠性很重要。
為業務層設計有效的日誌、審計和度量解決方案對應用程式的安全性和可靠性很重要。
為業務層設計有效的驗證解決方案對應用程式的可用性和可靠性很重要。
【第08章】 【數據層指導原則】
(P068)
必須確定一個策略來從數據源填充業務實體或數據結構，並且讓應用程式的業務層或表現層來使用。
(P069)
批量處理資料庫命令可以提升數據層的性能。每一次對資料庫執行環境的請求都產生一次開銷。通過批量化可以提高吞吐量、減少延遲以降低總開銷。因為資料庫可以為相近的查詢緩存並且重用執行計劃，所以批量處理相似查詢可以提升性能。
(P070)
如果數據以數據流形式來存儲和獲取，可以認為這是二進位大對象或 BLOB 。
BLOB 一般用來存儲圖片數據，但是還可以用來保存對象的二進位表示。
選擇合適的數據格式來提供和其他應用程式進行互操作的機制，以及利用序列化來跨進程和跨物理機器進行通信。數據格式和序列化特別重要的另外一個原因是能讓業務層存儲和獲取應用程式狀態。
(P071)
儘可能在貫穿應用程式的橫切組件中集中進行異常處理邏輯。
(P072)
從存儲過程的安全和性能來說，原則上應該使用參數化查詢和避免存儲過程中構建動態 SQL 。
要記住在存儲過程中使用動態 SQL 可能會影響性能、安全性和可維護性。
(P073)
事務是把一組有序信息的交換和相互關聯的行為當作原子單元，以滿足請求和確保資料庫完整性。只有當所有的信息和行為都完成，並且相關資料庫改變永久生效的時候，才認為事務完成了。在遇到錯誤時，事務支持撤銷 (回滾) 資料庫行為，這有助於保持資料庫中數據的完整性。
(P074)
預設情況下微軟 SQL Server 資料庫為每一個單獨的 SQL 語句作為一個單獨的事務來執行 (自動提交事務的模式) 。
設計有效的輸入和數據驗證策略對於應用程式的安全至關重要。
(P075)
DataReader 非常適合只讀向前的、每一行都能快速處理的操作。
如果您訪問的是 SQL Server 2008 ，可用 FILESTREAM 來得到訪問 BLOB 數據的可能和更大的存儲靈活性。
(P076)
除非要考慮可擴展性和安全性，否則可把數據訪問層和業務邏輯層放在相同的物理層中來以提高應用程式的性能。
【第09章】 【服務層指導原則】
(P081)
如果要通過服務提供應用程式功能的話，把服務功能分割為獨立的服務層很重要。
在服務層中需要定義和實現服務介面和數據契約 (或消息類型) 。更重要的是要記住服務永遠不應該暴露應用程式中內部的處理細節或使用的業務實體。
服務層應該提供翻譯組件翻譯業務層實體和數據契約之間的數據格式。
(P082)
服務把服務介面暴露給消息接收方。您可以把服務介面看作一個外觀，它把應用程式內實現的業務邏輯 (一般是業務層中的邏輯) 暴露給潛在的消費者。
(P085)
冪等的端點確保了只會處理一個消息，重覆的消息會被忽略。
(P086)
服務介面表示的是服務暴露的契約。契約定義了您的服務支持的操作以及這些操作相關的參數和數據傳輸對象。
對於服務介面的設計最大的錯誤就是把服務當作細粒度操作的組件。
(P087)
具象狀態傳輸 (REST) 和 SOAP 代表了兩種不同的實現服務的風格。從技術角度來說， REST 是一種架構模式，它使用簡單的動詞來構建，並且很適合 HTTP 。雖然 REST 架構原則可以應用到非 HTTP 的協議上，但是實踐中 REST 實現通常和 HTTP 聯合使用。 SOAP 是基於 XML 的消息協議，可以和任何通信協議一起使用，包括 HTTP 。
(P089)
為了簡單，可使用 ASP.NET WEB 服務 (ASMX) ，但是必須有運行微軟 Internet 信息服務 (IIS) 的伺服器。
如果您需要諸如可靠會話、事務、活動跟蹤、消息日誌、性能計數器以及支持多種傳輸協議等高級特性的話，可考慮使用 WCF 服務。
如果您確定為服務使用 WCF :
1. 如果您希望和非 WCF 或非 Windows 客戶端進行互操作，可考慮使用基於 SOAP 規範的 HTTP 傳輸；
2. 如果您希望支持區域網內客戶端，可考慮使用 TCP 協議和二進位消息編碼以及傳輸安全和 Windows 驗證；
3. 如果 WCF 客戶端位於相同機器，可考慮使用命名管道協議和二進位消息編碼；
【第10章】 【組件指導原則】
(P096)
應用程式的每一層都會包含一系列用於實現該層功能的組件。這些組件應該是高內聚松耦合的，以簡化重用和維護。
【第11章】 【設計表現組件】
(P103)
UI 的需求取決於應用程式需要支持的功能及用戶期望。
對於技術的選擇有一個很重要的因素，那就是 UI 需要的功能。
(P104)
根據 UI 的需求，可以確定應用程式的 UI 類型。有許多不同的 UI 類型，每一種都有其優缺點。
富客戶端移動應用程式可以支持離線的或間歇性的線上應用場景。而 Web 或瘦客戶端移動應用程式只支持持續連續的應用場景。
富互聯網應用程式 (RIA) 通常是具有豐富圖形用戶界面並且運行於瀏覽器中的 Web 應用程式。
如果應用程式的內容需要被 Web 搜索引擎搜索， Web 應用程式就很適合了。
基於控制台的應用程式提供了純文字的用戶體驗，一般運行在諸如命令和視窗或 PowerShell 的命令行外殼中。它們最適合於管理或開發任務，不太可能作為分層應用程式設計的一部分。
在為 UI 組件確定了 UI 類型之後，還必須選擇合適的技術。
(P105)
WPF 應用程式通過分離 UI 和底層控制邏輯為 開發人員 / 設計人員 提供交互 —— 允許開發人員關註業務邏輯，而設計人員關註觀感。
Silverlight 天生就支持非同步 JavaScript 和 XML (AJAX) ，它在 Web 頁面中通過 JavaScript 暴露其對象模型，可以使用這項技術讓 Web 頁面組件和 Silverlight 應用程式進行交互。
(P106)
AJAX 是 .NET 框架 3.5 以及之後版本中 ASP.NET 的重頭戲。
Silverlight 控制項和包含控制項的 Web 頁面可以通過使用 JavaScript 來進行交互。
在為 UI 選擇實現技術之後，下一步就是設計 UI 組件和表現邏輯組件。
UI 組件是一些給用戶顯示信息以及接受用戶輸入的視覺元素。在表現分離模式中，它們一般指視圖。
(P107)
除非需要特殊的顯示或特殊的數據集合，否則儘量避免創建自定義控制項。如果發現 UI 需求不能使用標準控制項來實現，可考慮購買控制項開發包而不是去自己寫自定義控制項。如果您必須創建自定義控制項，儘可能擴展既有控制項而不是去創建新的控制項。考慮通過附加控制項的行為對控制項進行擴展，而不是從控制項繼承，並且考慮為自定義控制項實現設計器支持，讓開發人員更容易使用。
表現邏輯組件處理用戶界面的非可視化方面的問題。包括驗證、響應用戶行為、 UI 組件之間的通信以及組織用戶交互。
如果 UI 需要複雜的處理或必須和其他層進行通信，可使用表現邏輯組件來和 UI 組件的處理進行解耦。
表現模型組件以一種表現層中 UI 和表現邏輯組件可使用的方式來表示業務層中的數據。
(P108)
表現模型組件應該儘可能同時封裝業務層中的數據以及業務邏輯和行為。
特定數據綁定技術可能需要數據源實現特定介面或事件來完全支持數據綁定，比如 WPF 中的 INotifyPropertyChanged 或 Windows Forms 中的 IBindingList 。
【第12章】 【設計業務組件】
(P113)
設計業務組件是一項很重要的任務，如果沒有能正確地設計您的業務組件，那麼代碼將變得難以維護和擴展。
(P114)
應用程式的整體設計和應用程式的類型決定了使用哪些業務組件來處理請求。
【第13章】 【設計業務實體】
(P119)
一般只在表現層需要或邏輯必須和基於 XML 的數據合作的時候才用 XML 。
要註意使用和操作 XML 會消耗大量的記憶體。
(P120)
微軟 .NET 框架提供了可以把 XML 數據反序列化成對象及把對象序列化成 XML 的組件。
必須確定如何跨邊界傳輸業務實體。在大多數情況下，當跨諸如 AppDomain 、進程以及服務介面邊界等物理邊界傳輸數據時，您都必須進行數據序列化。甚至在跨邏輯邊界傳輸數據時都要考慮進行序列化。
數據傳輸對象 (DTO) 是一種設計模式，它可以把多個數據結構打包成單個結構以進行跨邊界傳輸。
(P121)
領域模型使用實體、值對象、聚合根、資源庫以及領域服務進行表達，並將其組織成被稱作界定的上下文 (bounded context) 的職責分塊。
實體 —— 是領域模型中的對象，它們有唯一的標識並且在軟體狀態發生改變時不會改變。實體封裝了狀態和行為。
值對象 —— 是領域模型中的對象，用於描述領域驅動的某個方面。它沒有唯一標識而且是不可變的。
聚合根 —— 是一種類型的實體，它把邏輯上相關的子實體或值對象分組在一起，並對它們進行訪問控制以及協調它們之間交互關係。
資源庫 —— 負責接收和保存聚合根，一般使用 對象 / 關係 (ORM) 映射框架。
領域服務 —— 表示操作、行為或業務過程，並且提供引用領域模型中其他對象的功能。有的時候，某個功能或領域的某個方面不能映射到任何具有特定生命周期或實體的對象中，這種類型的功能可以聲明為領域服務。
【第14章】 【設計業務工作流】
(P123)
有三種基本的工作流風格 : 順序、狀態機以及數據驅動。對於順序工作流，任務在指定的一組步驟內遷移，直到其完成。對於狀態機工作流，活動被定義成一組狀態和事件，事件會將活動由一個狀態遷移到另一個狀態。對於數據驅動工作流，活動則根據數據相關的信息執行。因此，在設計工作流組件時，第一步是要理解您必須支持的工作流風格。
(P124)
你可以使用代碼、標記語言或代碼和標記語言組合的方式來編寫工作流。採用何種方式取決於您解決方案編寫模式的需求。
WF 提供了以開發人員為中心的解決方案，用於創建順序、狀態機以及數據驅動工作流。它支持純代碼、代碼分離及標記編寫模式。
(P125)
BizTalk 支持順序、狀態機和數據驅動工作流，以及代碼分離和標記編寫模式。
(P126)
微軟企業服務匯流排 (ESB) 工具包擴展了 BizTalk 的功能，它關註的是如何構建始終連接的、面向服務的應用程式。
【第15章】 【設計數據組件】
(P129)
數據層組件包含數據訪問組件和服務代理組件，其中數據訪問組件用於訪問系統邊界內承載數據，服務代理組件提供訪問其後端系統通過 Web 服務暴露數據。
(P130)
數據層應該利用數據訪問基礎結構統籌所有的數據源連接。
(P131)
不管是加密還是明文，都不要在資料庫中保存用戶密碼以供今後驗證。您應該是保存使用了鹽值 (為哈希的值指定一個隨機的位元組) 哈希後的密碼。
【第16章】 【質量特性】
(P135)
應用程式處理諸如可用性、性能、可靠性及安全性等質量特性的優劣程度反映了設計是否成功及軟體應用程式的整體質量。
每個系統對於每一個質量特性的重視程度和優先順序都不盡相同。
(P139)
延遲指的是響應任何事件之前的事件。
吞吐量指的是一定時間之內發生的事件數量。
應用程式的性能會直接影響其可伸縮性，並且缺乏可伸縮性也會影響性能。
(P141)
可伸縮性是在不影響系統性能的情況下處理額外負載的能力，或是增加負載量的能力。有兩種方式可提高可伸縮性 : 縱向伸縮 (向上擴展) 和 橫向伸縮 (向外擴展) 。如果需要進行縱向伸縮，那麼需要為單個機器增加諸如 CPU 、 記憶體及磁碟之類的資源。如果需要實現橫向伸縮，那麼需要為運行應用程式的農場增加更多機器來共用負載。
【第17章】 【橫切關註點】
(P148)
在跨物理邊界或進程邊界的時候考慮使用基於消息的通信，在進程內 (只跨越邏輯邊界) 考慮使用基於對象的通信。
消息隊列可以進行事務性消息遞送及支持可靠的只發一次的遞送。
(P151)
應該儘量讓緩存的數據靠近使用緩存的地方，這樣可以減少處理和網路往返過程，並且可以最大化性能和應用程式響應速度。
【第18章】 【通信和消息】
(P161)
為組件解耦不僅僅可以增進可維護性，而且可以提高靈活性，使得可以在將來更方便改變部署策略。
由於每一次跨邏輯或物理邊界的通信都會增加處理開銷，因此需要通過減少往返和最小化在網路上傳輸的數據量等方式來設計高效的通信。
(P162)
如果需要和其他系統進行互操作，則考慮使用 XML 序列化。但是要始終記住 XML 序列化會帶來更多的性能開銷。如果性能至關重要，那麼可以考慮使用二級制序列化，因為它更快，並且序列化後的數據也比 XML 序列化後的數據更小。
(P165)
考慮使用 DTO 來作為數據傳遞的一個單元，而不是每一次都傳遞獨立的數據類型。
【第19章】 【物理層和部署】
(P169)
對於非分散式部署，除了數據存儲功能之外的所有的功能和層都在一個伺服器中。
(P170)
對於分散式部署，應用程式的各層位於獨立的物理層。這種分層機制將系統的基礎結構組織成一組物理層的方式，通過這種方式可以針對特定運營需求和系統資源的使用情況對特定伺服器環境進行分別優化。
您需要謹記 : 增加更多的物理層也就增加了複雜度、部署工作量和成本。
您可以利用非同步調用、單向調用或消息隊列等技術來減少跨物理邊界調用時的阻塞。
(P171)
在設計分散式環境的時候，必須確定哪些邏輯層和組件會放到哪一個物理層中。大多數情況下，會把表現層放在客戶端或 Web 伺服器上；服務、業務和數據層放在應用伺服器上；資料庫則放在單獨的伺服器上。
確定在分散式環境中如何部署組件時，可以考慮如下指導原則 :
1. 只在必要時將組件分散式部署。實現分散式部署的常見原因包括安全策略、物理約束、共用業務邏輯和可伸縮性；
2. 如果表現組件需要同步使用業務組件，那麼可以把業務組件和表現組件部署在相同的物理層中，以最大化性能及簡化運營管理；
3. 如果出於安全性考慮，需要表現組件和業務組件之間具有信任邊界，那麼可以把它們部署在不同的物理層中；
4. 除非出於安全性考慮，需要服務代理組件和調用服務代理的組件之間具有信任邊界，否則可以考慮將它們放在同一個物理層中；
5. 儘可能讓非同步調用的業務組件和工作流組件部署在相同的獨立的物理層中；
6. 把業務實體和使用業務實體的組件放在相同物理層中；
(P172)
如果您正在開發一個需要訪問應用伺服器的客戶端程式，或正在開發一個會訪問獨立資料庫伺服器的單機客戶端程式，那麼您可以考慮兩層模式。
(P173)
對於三層設計，客戶端會和部署在獨立伺服器上的應用軟體進行交互，而應用伺服器又會和位於另一個伺服器上的資料庫進行交互。對於大多數 Web 應用程式服務來說，這是最常見的部署模式，而且也能滿足大多數一般的應用的需要。您可能會在客戶端和 Web / App 層之間實現防火牆，在 Web / App 層和資料庫之間又實現一道防火牆。
如果安全需求規定業務邏輯不能部署在邊緣網路中，或是應用程式代碼需要使用大量伺服器資源，您希望把相關功能的負載轉移到其他伺服器，那麼您可以考慮四層模式。
如果出於安全方面的考慮，不能把業務邏輯放在前端 Web 伺服器上，那麼可以考慮為 Web 應用程式使用分散式部署。可以為業務層使用基於消息的介面，並且考慮使用二進位編碼的 TCP 協議來和應用層進行通信，以獲得最佳性能。還應該考慮使用負載均衡來分發請求，這樣可由不同的 Web 伺服器來處理請求，並且要考慮在設計可伸縮 Web 應用程式時避免伺服器親和性，為 Web 應用程式設計無狀態的組件。
(P174)
對於 N 層部署，您可以把表現和業務邏輯放在客戶端，或只把表現邏輯放在客戶端。
“縱向擴展”就是升級正在運行的硬體，而“橫向擴展”則是通過把應用程式分發到多個物理器上來分擔負載。如果打算橫向擴展，一般會使用負載均衡策略，即負載均衡集群。
(P175)
負載均衡通過把客戶端的請求分發到多個伺服器，擴展了基於伺服器程式的性能，比如 Web 伺服器。負載均衡技術一般指負載均衡器，接收請求，然後在必要時將其轉發至某個主機。負載均衡主機併發響應不同的客戶端請求，即使多個請求來自相同客戶端。
根據路由技術，負載均衡器可能會檢測到無效的 Web 伺服器，然後把它從路由列表中移除，這樣可以將失敗帶來的影響降到最低。
如果每一個客戶端請求之間不需要進行跟蹤也不需要保存信息，換句話說通信是無狀態的，那麼負載均衡集群是最具伸縮性也是最有效率的。如果必須跟蹤狀態，那麼可能需要使用親和性技術和會話技術。
(P176)
在開發過程中，如果使用 Internet 信息服務 (IIS) 6.0 或以上的版本，可以配置 IIS 為 Web 園模式，幫助確保開發的應用程式正確處理了會話狀態。
Web 伺服器、 Web 農場一樣，如果業務層、數據層和表現層沒有位於相同的物理層上，可以通過應用農場的方式來橫向擴展業務層和數據層。將從表現層過來的請求分發到農場中的每一伺服器上，都有差不多的負載。根據每一層的需求及期望用戶個數的負載，應將業務層和數據層的組件放到不同的應用農場中。
(P179)
一般情況下，如果打算擴展應用程式，可以從兩種基本選擇中選擇一個或者兩個進行組合，這就是“縱向擴展”(讓盒子變得更大)和“橫向擴展”(用更多的盒子)。
對於“橫向擴展”，增加更多伺服器並且使用負載均衡和集群的解決方案。除了能處理額外的負載，“橫向擴展”應用場景還能緩解硬體故障的問題。
使用額外的處理器和增加記憶體的縱向擴展是一個經濟實惠的解決方案。這種方案還可以避免引入“橫向擴展”和使用 Web 農場和集群技術帶來的額外成本。應該先考慮“縱向擴展”選項，並且通過性能測試來檢查“縱向擴展”方案是否達到了制定的可伸縮性標準，以及是否在某種可接受的性能範圍內能支持必要的併發用戶數。
如果由於 CPU 、 I/O 或記憶體上的瓶頸，為解決方案進行“縱向擴展”不能提供足夠伸縮性，那麼必須進行“橫向擴展”和引入額外的伺服器。
(P180)
具有清晰遠程介面的松耦合的分層設計，相比緊密耦合的混亂交互的設計，更容易進行“橫向擴展”。由於分層設計天生就具有分離點，那麼在層的邊界進行“橫向擴展”就非常適合了。其中的訣竅是找到正確的邊界。
【第20章】 【選擇應用程式類型】
(P187)
在選擇應用程式類型的時候，您需要考慮需求、技術限制，以及最終的用戶體驗類型。
(P188)
每個應用程式類型都可以使用一種或多種技術來實現。使用場景和技術限制，以及開發組的能力和經驗都對技術的選擇有影響。
(P191)
RIA 應用程式一般依賴於一個客戶端的插件或一個托管的執行環境 (比如 XAML 運行時或 Silverlight) 。這個插件需要和遠程的 Web 伺服器進行通信， Web 伺服器可以生成客戶端插件或執行環境所需要的代碼和數據。
【第21章】 【設計 Web 應用程式】
(P196)
在設計一個 Web 應用程式時，考慮使用一些技術，比如緩存和輸出緩衝來降低瀏覽器和 Web 伺服器之間的來回通信，以及 Web 伺服器與其下游伺服器之間的通信。一個好的緩存策略可能是一個非常重要的跟性能相關的設計要點。
(P198)
授權決定著一個已經通過認證的身份是否可以執行某個任務，以及是否可以訪問某些資源。
您應該使用緩存來優化對引用數據的查找，避免網路往返通信的開銷，避免不必要的及重覆的提交。
(P200)
儘可能地使用 CSS 來佈局，而不要使用基於表格的佈局。
基於表格的佈局在渲染的時候會慢一些，並且在佈局複雜的時候會出現一些問題。
將客戶端腳本放在一個獨立的腳本文件中，這樣做可以被瀏覽器緩存。
(P201)
對於多伺服器 (Web 場) 的場景，並且必須在伺服器之間集中存儲 Session 數據，那麼考慮使用 SQL Server 狀態存儲。
【第22章】 【設計富客戶端應用程式】
(P209)
