The Biggest Flaw of Spring Web Applications | Java

開發人員在使用Spring應用是非常擅長談論依賴注入的好處。不幸的是，他們不是那麼真的利用它的好處，如單一職責原則，分離關注原則。如果我們一起來看看大部分Spring的Web應用程式，常見的錯誤的設計如下：

1.領域模型物件用來儲存應用的資料(當作DTO使用)，領域模型是貧血模型這樣的反模式。

2.服務層每個實體有一個服務。

問題是這樣很普遍，錯誤在哪裡呢？

Spring的web應用程式之所以這樣是因為他們做事物的方式一直都是這樣做的，老習慣難改，特別是如果他們是高階開發人員或軟體架構師，這些人捍衛這樣做的論據之一是：我們的應用程式遵循關注分離的原則，因為它已經被分為若干層，每個層有自己的特定職責。

1. Web層負責處理使用者輸入，並返回正確的響應返回給使用者。 web層與服務層通訊。

2.服務層作為一個事務邊界。它也負責授權和包含我們的應用程式的業務邏輯。服務層管理的域模型物件，並與其他服務和儲存庫層進行通訊。

3.儲存庫/資料訪問層負責與所使用的資料的儲存進行通訊。

分離關注(Soc)是分離計算機程式為不同的部分，每個部分有一個關注聚焦，一個典型的Spring Web應用在一定程度上遵循這一原則，但現實是，該應用程式有一個整體的服務層，它有太多的責任。更具體地，服務層有兩個主要問題：

1.在服務層發現業務邏輯

業務邏輯被分散在各個服務層。如果我們需要檢查一個業務規則是如何實現的，我們必須先找到它。這可能並不容易。此外，如果相同的業務規則需要在多個服務類，問題是，規則需要從一個服務到另一個簡單地複製。這將導致維護的噩夢。

2.每個領域模型一個服務

這完全違反了單一職責原則，它被定義為如下：單一職責原則指出，每一個類都應該有一個責任，責任應該由類完全封裝。其所有的服務應該狹義與責任相一致。(不應將原屬於領域模型的行為方法等劃放在服務中實現，物件不但有屬性還有行為)

服務類有很多依賴，以及大量的迴圈依賴。更像網路緊密耦合和單片服務。這使得很難理解，維護和重用。這聽起來有點苛刻，但一個Spring的web應用的服務層往往是最容易出問題的部分。幸運的是，所有的希望都不會丟失。

1. 我們必須將我們的應用程式的業務邏輯從服務層遷移到領域模型類中。

舉個例子：假設我是一個服務類，你是一個域模型物件。如果我讓你從屋頂上跳下來，你會喜歡我這樣的決定嗎？(跳下來會摔傷，自己沒有腦子或被洗腦，變成殭屍，只聽從執行，不思考自己的安全，這就是貧血模型的問題)

將業務邏輯從服務層遷移到域模型類有下面三個優勢：

(1)我們的程式碼將以邏輯方式切割，服務層只要關注應用邏輯，而我們的領域模型關注業務邏輯。

(2)業務邏輯只存在一個地方，容易發現修改。

(3)服務層的原始碼是清潔的，不包含任何複製貼上程式碼

2. 將每個實體服務切割為單一目標的更小的服務。

比如，有一個單一服務類，提供對人員和使用者賬戶的CRUD操作，我們應該將它分為兩個獨立的服務類：

第一個是對人員的提供CRUD操作

第二個是提供與使用者賬戶相關的操作。

好處：每個服務類中有一個邏輯組職責。每個服務類的依賴較少，這意味著他們不再是緊耦合的源頭。他們是較小的和鬆耦合的元件。服務類更容易理解，維護和重用。

這兩個簡單的步驟將幫助我們使得我們的應用程式架構更乾淨，有助於同行開發商提高生產力和幸福。