軟體架構--服務層

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

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

<a href="http://3983901.blog.51cto.com/attachment/201205/21/3973901_13376130133CpX.png"></a>

   我的了解是服務層是處于我的應用程式業務層和表現層之間的應用程式邊界,邊界可能是很薄的一層類設計或者是分布式服務網絡躍點。它是一個與技術無關的名詞。由表現層直接調用，契約，執行指令（修改狀态（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的直接使用。根據世界項目，情形由我們的架構師決定。

 本文轉自 破狼 51CTO部落格，原文連結：http://blog.51cto.com/whitewolfblog/871896，如需轉載請自行聯系原作者