我試圖設計一個具有豐富模型(貧血模型是不好的OO實踐)的領域層。我還從DDD瞭解到,它不排除服務對象,並且良好的領域層設計是將領域邏輯分成領域模型和服務對象的健康平衡。不過,如果業務邏輯應該在域模型和服務對象之間劃分,那麼應該在哪裏繪製線?換句話說,我如何知道業務邏輯是屬於域模型還是服務對象?是否有經驗法則規定某些行爲應該轉到域模型而其他行爲屬於服務對象?請讓我知道你是否可以提供一點點提示,謝謝。域模型和服務對象中的業務/域邏輯
0
A
回答
1
1
良好的領域層設計正確地模擬領域概念和用例。由您決定什麼是聚合根(AR)以及作爲服務的資格。每個人都有自己的經驗和喜好。
個人而言,我使用服務來實現用例。這意味着它們具有狀態,雖然非常不可變,狀態是實現細節(我可以用靜態方法寫入相同的事情,將所有的deps作爲方法的參數傳遞,而不是在構造函數中注入必需的存儲庫和其他服務)。
最重要的是要確保您瞭解業務概念,行爲和用例。這應該是顯而易見的,許多人對此很淺薄,而且結果的設計很不妥,難以維護。
我建議採用更自然的方法。只需開始建模,不要問自己它是一個AR,還是價值對象,或者它應該是一個服務等等。隨着你的進步,你會很清楚。
你可以做的最糟糕的事情是提出一些人爲的規則/約束,並根據這些規則爲你的域(和實際的整個應用)建模。 DDD是關於讓域驅動設計。術語和技術細節是實現細節,可隨時更改,不要將它們用作設計指南。
相關問題
- 1. 域對象中的業務邏輯
- 2. 域邏輯和業務邏輯
- 3. 業務邏輯和服務
- 4. 模型邏輯和服務層邏輯
- 5. 業務邏輯應該放在域還是服務中?
- 6. 如何將業務邏輯添加到域驅動設計中的域服務?
- 7. 域對象和服務
- 8. 貧血域模型和域服務
- 9. 邏輯模型和領域模型
- 10. 模糊邏輯域模型
- 11. 在模型中實現業務邏輯
- 12. RIA服務中的業務邏輯
- 13. 業務對象和業務邏輯有什麼區別
- 14. 存儲庫,服務或域對象 - 邏輯屬於哪裏?
- 15. 如何分離模型(業務邏輯和商店邏輯)?
- 16. 業務邏輯的PHP對象服務器
- 17. 服務層模式:跨越多個服務的業務邏輯
- 18. MVC業務邏輯訪問模型
- 19. 您的域模型對象中應該有多少邏輯
- 20. 經營業務邏輯對象
- 21. 業務邏輯
- 22. 邏輯模型與域模型
- 23. 服務器端業務邏輯和WCF RIA服務
- 24. C#業務邏輯,業務對象,數據訪問,項目
- 25. ServiceStack服務與業務邏輯分離
- 26. Qt GUI和業務邏輯模塊
- 27. EF6和業務邏輯層
- 28. MVVM和業務邏輯層
- 29. 將域業務邏輯包含在域驅動架構中的地方
- 30. 域模型 - 業務驗證/錯誤
知道域服務不應該有狀態並不意味着它不能檢查它正在使用的對象的狀態(它們可以依賴於它們操作的聚合狀態)。基本transferFundsDomainService可能需要檢查是否有一個帳戶爲事務打開,如果不是,服務將失敗。 Jimmi Bogard也有一些推動不當設計(即實體驗證)的帖子。 –
是的,的確,謝謝澄清 –