2014-01-31 398 views
0

我試圖設計一個具有豐富模型(貧血模型是不好的OO實踐)的領域層。我還從DDD瞭解到,它不排除服務對象,並且良好的領域層設計是將領域邏輯分成領域模型和服務對象的健康平衡。不過,如果業務邏輯應該在域模型和服務對象之間劃分,那麼應該在哪裏繪製線?換句話說,我如何知道業務邏輯是屬於域模型還是服務對象?是否有經驗法則規定某些行爲應該轉到域模型而其他行爲屬於服務對象?請讓我知道你是否可以提供一點點提示,謝謝。域模型和服務對象中的業務/域邏輯

回答

1

由於域服務是域模型的一部分,因此我假定您的意思是域服務與域對象。

Toran Billups給出了類似的回答here,Jimmy Bogard博客文章here

作爲一般的經驗法則:域服務是無狀態的,而域對象有狀態。因此,任何依賴於內部狀態的東西都會進入域對象,不依賴於當前狀態和/或概念上不適合單個域對象的概念將由域服務建模。

+0

知道域服務不應該有狀態並不意味着它不能檢查它正在使用的對象的狀態(它們可以依賴於它們操作的聚合狀態)。基本transferFundsDomainService可能需要檢查是否有一個帳戶爲事務打開,如果不是,服務將失敗。 Jimmi Bogard也有一些推動不當設計(即實體驗證)的帖子。 –

+0

是的,的確,謝謝澄清 –

1

良好的領域層設計正確地模擬領域概念和用例。由您決定什麼是聚合根(AR)以及作爲服務的資格。每個人都有自己的經驗和喜好。

個人而言,我使用服務來實現用例。這意味着它們具有狀態,雖然非常不可變,狀態是實現細節(我可以用靜態方法寫入相同的事情,將所有的deps作爲方法的參數傳遞,而不是在構造函數中注入必需的存儲庫和其他服務)。

最重要的是要確保您瞭解業務概念,行爲和用例。這應該是顯而易見的,許多人對此很淺薄,而且結果的設計很不妥,難以維護。

我建議採用更自然的方法。只需開始建模,不要問自己它是一個AR,還是價值對象,或者它應該是一個服務等等。隨着你的進步,你會很清楚。

你可以做的最糟糕的事情是提出一些人爲的規則/約束,並根據這些規則爲你的域(和實際的整個應用)建模。 DDD是關於讓域驅動設計。術語和技術細節是實現細節,可隨時更改,不要將它們用作設計指南。