在領域模型模式中，我們大都是將服務層看作是業務層的一部分。雖然這個做法非常常見，不過顯然，我們還有其他選擇。通常來說，服務層爲表現層定義了一個接口，從而允許表現層觸發一些預定義的系統操作。正如名稱表現出來那樣，服務層可以看作是表現層結束、業務邏輯層開始的一個邊界，服務層用來儘可能的降低表現層和業務邏輯層之間的耦合，讓表現層無需關注業務邏輯層中的具體實現組織方式。因此，無論你選擇任何一種業務邏輯模式（表模塊、活動記錄還是領域模型），系統都可以提供一個服務。
實際上服務層不執行任何具體的工作，其功能在於組織各個業務對象，服務層非常瞭解業務邏輯（包括工作流、組件和服務），進而也非常瞭解領域模型。服務層不僅組織業務組件，還組織應用程序專有的服務、工作流以及其他任何出現在業務邏輯層中的特殊組件。
用“服務”作爲表現層和業務層之間的層的名字是有爭議的。這一層可以通過Web服務或WCF服務實現，也可以選擇其他的任何一種技術。雖然服務層有“服務”一詞，但是我們要將它理解成一個與技術無關的詞彙。
服務層位於系統中兩個互相通信的邏輯層之間，使兩個層能夠在鬆散耦合並優美彼此離開的同時，仍舊可以完美地彼此通信。
每個用戶驅動的交互的核心都包括兩個參與者：表現層的用戶界面和服務層實現的用來響應用戶操作的模塊，這就是說服務層不僅用來組織業務邏輯，也許要與持久化層進行交互。所有的交互都源於表現層，並從服務層獲取響應，根據接收到的輸入，服務層將組織業務邏輯層中的組件 - 包括服務、工作流和領域模型中的對象，並根據需要調用的數據訪問層。
不僅僅只有服務層會發送數據庫操作請求，也許還有其他情況，業務邏輯層也可能包含一些工作流、或業務服務需要使用到的數據訪問層。業務邏輯層唯一需要完全和數據庫細節分離的部分就是領域模型。
面向服務
通常來說，服務層就是一系列暴露了邏輯上相關方法的類，供其他層（通常是表現層）調用。在這種抽象層面上，服務層和事務腳本庫非常類似。離開了技術上下文，“服務”一詞就簡單的表示能夠爲某一層提供服務，並把請求發送給另一層的軟件組件，而“服務層”則表示位於兩個需要通信的層之間的、一系列服務的集合。直接了當的說，目前越來越多的人認爲“服務”並不僅僅是一些能夠處理請求的代碼，出現這種狀況的一個主要原因是面向服務和麪向服務架構SOA的日益流行。
面向服務是一種設計業務的方式，由一系列互相連接的服務組成，面向服務並不是某種特定的技術，而更像是一種不同的組織業務操作的方式。在SOA的世界中，應用程序是由一系列獨立的服務經過組合和集成得到的，這個集成的過程可能類似於以前流行的快速應用程序開發中的窗體設計過程。不過在SOA應用程序中，最小的構建塊是服務，而不是組件。
服務可以充分使用其所處的環境，且其生命週期控制也更加自主。服務層中的服務要比簡單的類更加適合，甚至可以說，若不是爲了實現服務，甚至沒有必要獨立成專門的服務層。
服務可以自治、可發現資源、和固定接口。除此之外，服務通常被設計成一個無狀態的組件。一般來說，無狀態的組件可伸縮性比較好，其整體實現也相對簡單，且能應用在更多的不同場景中。
服務層中的服務
從架構上講，服務層應用了軟件設計中一個通用且人人皆知的原則低耦合。可能還應用了另一個原則高內聚。這是一個通過中間層解除用戶界面和中間層的耦合來實現的。
面向服務的出現讓架構師更興致勃勃的將一些面向對象服務特性應用到服務層中，結果就是所有的服務層都是由且僅由一些服務組成。服務層作爲模式存在的根本原因就在於，服務和麪向對象的概念已逐步應用到內部應用邏輯以及外部客戶操作之上。
服務層可以作爲一個遠端的層，不過根據實際情況取決於項目的客戶端。服務層也可能是表現層中的一部分。如果那樣，服務層不需要設計成Web服務，而是可以用支持服務的組件或一些普通的類來實現，這裏的重點是服務層所提供的抽象，而不是其具體的實現方式。支持服務的組件是指.Net Framework類支持COM+服務的機制，當你需要使用一些COM+提供的額外服務，例如，實時激活、對象池、聲明式安全或分佈式事務等。例如WCF是需要遠程調用時，作爲服務層創建服務的良好選擇。WCF作爲一種服務技術來說，其最大的優勢就是其配置能力能夠方便的向解決方案中添加一些面向方面的特性。
服務層作爲用戶界面和中間層提供了一個統一的契約，因此中間層即可專注於實現應用邏輯。應用邏輯屬於業務邏輯的一部分，其設計直接源於需求中的用例。若沒有了服務層，則需要從表現層直接調用到應用程序服務中，這就會造成一個太過細粒度的遠程接口，從而導致過多的交互。
服務層是由一系列粗力度的服務組成的，這也叫做宏服務。宏服務是按照用例來組織操作的，其中並不包含任何核心業務相關的領域邏輯。表現層和服務層都不（或者不應該）包含業務邏輯，表現層僅僅瞭解服務層提供的粗粒度接口，服務層僅僅瞭解一系列可用的交互方式，並關注一些具體細節，包括必要的事務、資源管理、協調、數據轉換。
服務層實戰
何時使用：服務層應該用在有一定複雜性的應用程序中，只是隨隨便便、簡簡單單使用幾周的Web站點，服務層也不能帶來一些開銷和好處。SOA和web服務確實存在關係，SOA不是Web服務，不過某個Web服務可能是SOA架構的產物。SOA是設計哲學，而不是編寫服務的具體技術。
位置在哪裏：服務層的位置是在本地還是遠程調用取決於當前情況。若服務層可以容易地在各個物理層中移動，那將是個最好的結果。這樣看來，類似WCF的服務技術是一個最好的選擇。在將服務層中的某個類升級成服務並不是個大動作，這個操作通過重構解決。
處理角色和安全：若對安全非常在意，那麼可以讓服務層中的每個方法都檢查調用者的標識，並拒絕未認證用戶的訪問。若不想在每個服務中都重複檢查，那麼可以採用聲明式的方法保證安全，即爲服務方法添加安全相關的特性。
面向服務架構
分佈式系統中對服務層的關注點和需要是與面向服務緊密相關的。面向服務是一種理念，讓你將軟件架構的功能看作是一系列業務流程的集合，這些業務流程被封裝並暴露成一系列可以交互操作的服務。
SOA的原則是：邊界清晰、服務自治、使用契約，而不是類、兼容性基於策略。
邊界清晰：SOA服務將顯示暴露出清晰的契約，所有與該服務的交互都要通過該公共接口進行。在設計服務時，開發人員應該儘可能讓接口簡單，同時又不影響日後的增強。
服務自治：自治服務是一個鬆散耦合的服務，該服務的設計和部署都獨立於其他服務，但是可以通過基於契約的消息和策略與其他服務進行通信。服務應該設計成靜態的，且在服務發佈之後不應該再有修改，若想滿足該需求，就必須選擇基於消息的語義，因爲其靈活性允許你將他作爲契約的一部分。
使用契約、而不是類：無論選擇各種技術，都是通過基於常用、規定的數據格式來傳遞數據的。定義服務就是定義服務契約以及一系列數據契約。
兼容性基於策略：服務可達並可調用並不能成爲使用者調用該服務的原因，關鍵之處在於使用者必須能夠判斷某個服務是否滿足了它的需求。服務和數據契約指的是結構的兼容性，也就是某個指定的服務是否能完全滿足使用者的期待，語義兼容性也應該通過一個公開可訪問的、標準的策略暴露出來，供外界查看。
很多SOA模式在服務層適用，但是反模式也值得介紹。SOA反模式常見的兩種是：CRUDy和Chatty聊天式模式，這兩個模式都是有關服務契約的。CRUDy接口只是一個漂亮的名字而已，真正的敵人是糟糕的設計。與CRUDy相關的是聊天式模式，該反模式描述的是某個服務契約以類似PRC的方式交流行爲。換句話說，這種服務暴露了表現層一系列細粒度的方法，表現層要一個接一個的調用才能完成需要的操作。
小結
服務層一般總是有必要提供的，因爲它能夠解除應用程序接口和中間層之間的耦合。唯一不會考慮使用服務層的情況是，你非常確定程序有且僅有一個表現層。
相關博客：
- .Net企業級應用架構設計之當代的架構師和架構
- .Net企業級應用架構設計之UML
- .Net企業級應用架構設計之設計原則和模式
- .Net企業級應用架構設計之業務層設計
- .Net企業級應用架構設計之服務層設計
- .Net企業級應用架構設計之數據訪問層
- .Net企業級應用架構設計之表現層設計