哪裏需要從數據庫中獲取數據的域邏輯

Question

我知道域邏輯應該放入域對象。但是，如果我的域邏輯需要來自數據庫的數據呢？ （例如檢查唯一值，計算值等等）我認爲將存儲庫注入到我的域對象中並不是正確的。此外，服務層不應包含業務規則。那麼如何解決這種業務邏輯呢？

Answer 1

你是對的，你的域對象不應直接從數據庫中讀取數據。這裏的經典錯誤是域對象通過Web服務發送，並嘗試從數據庫讀取數據，當數據庫位於服務器上而不訪問數據庫時。

有幾種方法可以做到這一點：

• 服務層預加載任何信息的域對象需要
• 域對象可以調用輔助或存儲庫從數據庫
獲取數據

Answer 2

我一直覺得服務層是一個合乎邏輯的地方調用這種類型的活動 - 但我會解釋，這不是在那裏我實現了它本身。由於服務層是您進入域的入口，因此您可以確信，無論請求何時啓動對此數據的需求，它都必須通過這一點才能實現。

此外，讓服務與其他服務對話是非常乾淨的，因爲它們專門設計爲需要最小的努力來調用。您可以在存儲庫中公開您需要的適當功能（即可以爲您提供匹配Y條件的X對象的計數的方法/查找程序/查詢），並將其包裝在方便的服務調用中。這不僅可以讓您在單一服務中輕鬆完成任務，還可以在服務之間利用此功能來實現更復雜的需求。

我明白在將業務邏輯放入服務層時需要注意的一點，但根據需求，它是什麼是業務邏輯和什麼是特定於實現的業務邏輯之間的一條細線。在編寫一個系統時，經常會出現一些表面上隱含的業務邏輯但不適合的規則。獨特的約束是我發現的最常見的例子。請記住，就像存儲庫中的所有其他內容一樣，這不是服務層中的實現，而是對域中已有內容的抽象。

我所做的是將「邏輯」本身置於域中，通常以規範模式實現的形式。由於邏輯是在存儲庫中執行的，並且不需要更改服務層，所以我接受了這個完全可以接受的條款。你會發現適用於實體集合的規則通常是「有趣」的規則。如果您只需要驗證聚集根中的某個集合是否具有唯一性，那麼這很簡單。

我已經看到了域對象知道存儲庫的方法，我個人不是粉絲。對我來說，存儲庫是定義域如何與持久層接口（儘管不一定是實現）。事實上，一個實體甚至知道它有一個更大的目的而不僅僅是存在，使事情變得非常複雜。