在Spring框架中最常見的幾個注解
@Controller, @Service, @Component, @Repository
其中@Component是一種通用名稱，泛指任意可以通過Spring來管理的組件，@Controller, @Service, @Repository則是一種特定的組件，通常用來表示某種特定場合下的組件，比如@Repository用來表示倉庫（數據層，DAO），并且Spring 框架會根據這種應用場景做些定制，比如@Repository同時具備了自動化的異常轉換。類似的， @Service則用來表示服務層相關的類， @Controller則用來表示展示層（presentation）的類。
那Service是什么呢？
Service 表示了在軟件分層設計中的Service層，用來連結數據層（DAO）和展示層（Presentation）。
為什么要在DAO層上加一層Service呢？
對Java技術，架構技術感興趣的同學，歡迎加QQ群：863621962，一起學習，相互討論。
在某些簡單的應用中，DAO層的功能和Service的功能很接近，甚至初學者會覺得Service層做的事情和DAO層都一樣，那為啥還要將Service層單獨拿出來做一遍呢？而且，很多場景下，Service層和DAO層同時存在，往往會增加代碼復雜度，編碼工作量，寫的不好甚至會造成混淆。
通常來說，DAO層應盡力保持簡單，其功能僅僅是提供了數據庫的連接，以及最簡單的增刪改查（Crud），有時還需要做些抽象，以此來連接使用不同技術的數據庫。除此之外，任何業務相關的操作都應該放到Service層，即Service層用來編寫業務邏輯，即操作從DAO層讀取的數據，或者將處理好的數據給DAO層，當使用Domain Driven Design時， 這兩個類通常會放到同一個Domain（包）中，即便在簡單的應用中，他們的代碼可能極其類似，但是仍應該分別對待。而不是跳過service層（service）直接去使用DAO層（repository）來放業務邏輯數據。
這樣帶來的好處帶來更好的模塊化結構，有便于后期的擴展和維護，比如更換數據庫實現時，我們僅僅需要處理DAO層的內容就好了。并且，當業務邏輯比較復雜的時候，比如有很多報告要出的時候，Service層就提供了一個很好的空間來實現這些代碼。
其次，在web應用開發中，使用Service層可以將web類的活動限制在controller中，這樣可以獨立的測試service層
另外，還有一種情況，就是當應用極其復雜，需要同時使用多種數據庫時，將從DAO中獲取數據的動作放到一起可以減少數據庫的操作，并且可以保證數據的一致性。同時Service可以嵌套，因此如果需要使用不同的數據庫時，可以在service中指定。
在Service中也可以放一些通知類的操作，比如發送郵件等，這樣也可以保持controller的整潔。
還有一個潛在的好處是安全性，當使用service層包裹DAO層后，數據庫的鏈接是被service層保護起來的，這樣如果客戶端被某種情況攻陷，其只能使用service層提供的有限數據，而無法直接攻擊數據庫
另外，在Spring 框架中，security也是在Service層實現的。根據上面的邏輯，我們在實際開發中，應該不去實現自己的DAO層，而是使用Spring Data JPA，因為Spring Data JPA已經實現了DAO層。
這種寫法常見的問題有啥？
最常見的寫法（或者是錯誤的寫法）有以下幾種
1、面向領域的模型對象僅僅用來存儲應用中的數據，換句話說，是不太符合domain model 設計的
2、處理模型數據的業務邏輯分散在service層
3、每個entity都有對應的service類
對Java技術，架構技術感興趣的同學，歡迎加QQ群：863621962，一起學習，相互討論。
這樣寫的原因很大程度來源于上面的分層理論，我們確實將應用分成了展示層（web layer），服務層（service layer），數據層（repository/dao），但是實際后果卻是一個極其龐大的service層，這種寫法可以算是一個面向過程開發的代碼（procedural code）， 而不是面向對象開發。好處是簡單，當業務不復雜時，確實沒有必要使用一個龐大的面向對象開發框架（domain driven design）。
一個責任并不明確的service層主要有以下問題
1、業務邏輯分散在service層中，當我們需要確認或者檢查某個業務邏輯時，可能要在多個service類中尋找，也許并不那么容易，另外如果同樣的業務邏輯在多個service類中用到時，那么可能會存在大量的重復代碼，這種重復代碼對于維護人員來說就是惡魔。
2、在service層中，每個entity都有對應的service類時，service層會有過多的依賴，甚至是循環依賴關系，而不是由松散耦合的service類構成service層，理想中的service層應該是由具有單一責任的service類構成，并且這些service類具有松耦合關系，如果不是這樣的service層，將難以理解，維護和重用。
主要的解決方法是
1、將與entity相關的業務邏輯統一放到領域模型對象相關的類中，即所謂的domain service中。這樣做的好處時，傳統概念中的service層僅僅處理應用相關的業務邏輯，即作為Application Service。 然后domain service中處理domain 內的業務邏輯。業務邏輯將按照domain和application的方式分開，容易定位和維護。傳統意義上的applicationservice層將變得整潔。
2、在domain service中我們將按照entity來編寫對應的service，這些都是特定的service，很小，僅僅面對很專一的功能。舉例來說，如果應用中的某個service提供person類的crud， 同時還提供用戶帳號的操作，那么我們應該將person的crud單獨放到一個service中，然后將用戶帳號相關的操作放到另一個service中。
所有這些分層方式都是為了解決應用從小項目成長為大項目時可能遇到的隱患，代價是在項目還小時，增加了項目的復雜度，往往一句代碼就能搞定的事情，卻要拆到三個類中去。但是太多的實際例子表明，如果沒有好的架構，當小項目膨脹到一定程度時，往往是無法維護的，只能全部推倒重寫。
在Domain Driven Design中如何區分各種Service？
在DDD中，service有三種類型
Domain Service
Domain Service: 用于放置領域對象相關的業務邏輯，這些業務邏輯通常并不適合放到entity中，也不是常見到的CRUD(這些應該放到Repository)， 將Domain Service 和Domain Objects放到一起是合理的，它們都是關注于domain相關的業務邏輯。在Domain Service中可以使用注入repository的方式來使用entity對應的repository。
舉一個例子：
一個圖書館有三個entity：Book， Client，Inventory， 當把一本書借給一個客戶時，就對應了一個Domain Service。在一個例子，在Eric Evans的《Domain Driven Design》書中，轉賬服務（FundsTransferService）也是一種domain service，它涉及到帳號BankAccount，但是并不適合放到BankAccount中。
Application Service
Application Service: 用于為應用外的client或consumer提供應用級別的服務，比如一個外部客戶端（程序）需要使用某個entity的CRUD時，這些服務程序放到Application Service。
Application Service通常會使用Domain Service和repository來處理外部的請求。常見的場景是，從repository中拿到一些domain objects， 然后執行某些操作，在將其放回repository（或者不放）， Application Service對應著大部分用戶使用場景，在寫一個應用時，可以先從Application service寫起，這樣可以很好界定應用的功能和范圍。repository雖然可以在某些場景下注入到domain service中，但是更常見的是注入到applicatinoservice中。
Infrastructure service
還有一種Infrastructure service：用于抽象一些技術問題，比如消息隊列，郵件服務
具體例子spring-petclinic
以上就是我的分享，看完的朋友記得點贊噢！想學習更多的Java技術方面的知識的朋友們，可以進我的Java高級架構師交流群，里面有高可用、高并發、高性能及分布式、Jvm性能調優、Spring源碼，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料，群號：680075317，也可以進群一起交流，比如遇到技術瓶頸、面試不過的，大家一些交流學習！
