在ddd設計中我們經常會提到服務層，服務層是什么？職責是什么？有什么好處？。

先看簡單的層次圖（注：這里并沒有考慮其他多余的領域邏輯數據層存儲，或者UOW這些細節）

我的理解是服務層是處于我的應用程序業務層和表現層之間的應用程序邊界,邊界可能是很薄的一層類設計或者是分布式服務網絡躍點。它是一個與技術無關的名詞。由表現層直接調用，契約，執行命令（修改狀態（CUD））或者是查詢返回dto（數據遷移對象）（cms，命令-查詢分離）。他對業務邏輯層接口很清楚，組織業務邏輯 微服務形成宏服務，適配表現層。

這里談到宏服務和微服務，宏服務有一些列粗粒度的服務組成。用戶的一次操作usecase，比如電子商務下單，CreateOrder就是一個宏服務，而不是下單中的細粒度的商品庫存檢查，訂單合法性等。而與之對應的微服務（有時也叫應用程序服務），則表現為問題領域邏輯細節，就如上面的庫存檢查和合法性檢查這些細粒度的服務。宏服務是由一個或者多個微服務組成，有時我們的usecase邏輯很簡單服務層僅由單一微服務組成，變現為很簡單的幾句微服務調用。

服務層的職責：

1：在面軟件開發不管是結構化編程（sp）還是面向對象編程（oop）我們一直都強調高內聚低耦合，分離關注點（soc）。服務層處于應用程序和業務層之間，應用邊界，使得兩次直接解耦，利用第三個對象破壞兩對象直接的依賴，并轉化適配領域對象（do）和試圖對象（vo）的差異。

2：服務層隱藏了業務邏輯層的細節，其內部需要組織業務微服務，提供更宏觀，面向表現層的服務邏輯，利用契約接口暴露，包裝。系統所有的交互都是從表現層進入。

目前流行SOA架構，提供了一種分布式服務架構，以服務為關注點，提高服務和業務邏輯的重用，但是這里說的服務并不是特定的技術wcf或者 webservice，服務同時候可能是一次規定契約的一些列粗粒度組織的類組成。但是利用SOA或者MTS建立服務會讓我們的服務得到跟多的附加優勢，例如安全，事物，日志，擴展性的提升。

服務層帶來的優勢：如上所述服務層為表現層提供的同一的接口契約和入口。讓我們的業務層可以關注與實現問題領域邏輯，問題領域實際需求。組織微服務避免太多的細粒度服務的調用充斥在我們的項目表現層和問題領域中，過多的交互。如果采用soa等服務領域可以讓我們的應用程序輕易的跨過應用程序邊界和網絡躍點。但是需要付出一點的性能代價。

數據遷移對象（dto）就是攜帶數據穿過應用程序邊界的對象，減少數據的交互次數，常常我們將其作為值對象，只是一組簡單的get，set屬性組成，不存在行為操作，僅僅為數據的載體。在領域設計中dto是一個很重要的模式，不是我們所有的領域對象都能輕松的到達表現層，僅僅表現層和領域層部署在同一物理位置。如果需要穿過網絡躍點或者進程邊界，因為領域對象使我們的業務的核心存在很多的自然世界的關系，依賴，甚至可能存在循環依賴比如電商用戶和訂單，用戶用戶一組訂單的集合，而每個訂單都指向一個特定的用戶，我們就必須破換掉這種循環依賴，才可能使其可序列化，穿過躍點。其次我們的領域對象往往都是一堆領域富對象，存在大量數據，很多時候我們的場景并不需要全部的數據信息。有了dto的存在就能很好的解決這些問題，是的我們的項目變得 simple（keep it simple，Stupid。 KISS原則）。

但是與此同時dto存在會為我們帶來一些額外的復雜度，我們必須有一層do到dto的映射適配層。

理論上***的設計我們需要為每一個應用定義一個dto，但是在一個復雜的系統中我們可能存在很多的領域對象，加入500個do，每個do一般都會存在多個 dto，這將一個增加一個龐大的集合和mapping邏輯，對于維護也存在不小的挑戰。在軟件領域存在一句話就是bug的數量隨著代碼量增加，代碼量增加需要測試點也隨著增加。除非我們必須跨越應用程序網絡躍點邊界，我覺得否則我們也可以存在一些簡單do的直接使用。根據世界項目，情形由我們的架構師決定。

原文鏈接：http://www.cnblogs.com/whitewolf/archive/2012/05/21/2512354.html