在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的存在就能很好的解決這些問題，是的我們的專案變得******（keep it ******，stupid。 kiss原則）。
但是與此同時dto存在會為我們帶來一些額外的複雜度，我們必須有一層do到dto的對映適配層。
軟體架構設計系列總結
出處 架構引用 維基百科 軟體體系結構是構建 計算機軟體 實踐的基礎。與建築師設定建築專案的設計原則和目標，作為繪圖員畫圖的基礎一樣，乙個 軟體架構師 或者系統架構師 陳述軟體構架以作為滿足不同客戶需求的實際系統設計方案的基礎。從和目的 主題 材料和結構的聯絡上來說，軟體架構可以和建築物的 架構相比...
軟體架構設計系列總結 8 資料訪問層簡述
在前面簡單描述了下 服務層，soa面向服務架構，架構設計 業務邏輯層，以及一些面面向設計原則理解和軟體架構設計箴言。這篇部落格我們將繼續進入我們的下一層 資料訪問層。無論你用的是什麼開發模式或者是業務模式，到最後最必須具有持久化機制，持久化到持久化介質，並能對資料進行讀取和寫入crud。這就是資料訪...
軟體架構設計系列總結 8 資料訪問層簡述
在前面簡單描述了下 服務層，soa面向服務架構，架構設計 業務邏輯層，以及一些面面向設計原則理解和軟體架構設計箴言。這篇部落格我們將繼續進入我們的下一層 資料訪問層。無論你用的是什麼開發模式或者是業務模式，到最後最必須具有持久化機制，持久化到持久化介質，並能對資料進行讀取和寫入crud。這就是資料訪...