域模型中域對象的集合

這可能是一個基本問題，但我對DDD很新穎。我有一個域對象，我們將其稱爲可以從UI批量處理的調整。在我們處理調整之前，我們需要驗證這些調整將應用的日期。我的問題是在我的域對象中的IsValidDate（）方法的位置。域模型中域對象的集合

它應該是調整類中的靜態方法嗎？
它應該是AdjustmentService類的一部分嗎？
我應該創建一個AdjustmentsGroup域對象來包含一系列調整，並且還會實現IsValidDate嗎？

我會傾向於認爲第三個選項是最好的選擇，但我很難考慮調整對象組的領域術語。爲這種類型的場景「強制」一個容器類型的域對象是否可以？有沒有一種常見的做法來處理這個問題？

謝謝

編輯：IsValidDate實際上包含業務邏輯。這不僅僅是一個簡單的日期驗證方法

來源

2009-12-14 Benoit Martin

'AdjustmentsGroup'本身聽起來像是一個很好的領域術語 - 假設沒有其他聚合根是適合此集合的家（並且它對您的領域專家有意義）。 – 2009-12-14 20:21:08

不得不同意傑夫 - 「AdjustmentsGroup」聽起來像是一個自然適合與領域專家對話的術語。它還強制執行DDD的另一個原則：「明確隱含概念」 – 2009-12-15 08:27:57

我會投票贊成2）讓它成爲DomainService。實現它的代碼可以位於DomainServices類，AdjustmentServices類或ValidateAdjustmentService類中，具體取決於域模型中的其他服務，以及從組織角度最有意義的代碼。

另一種選擇（如果由該服務實現的規則是業務規則）是將其作爲SPECIFICATION實現。（在DDD中查看第224-240頁）

來源

2009-12-14 19:24:07

謝謝你的回答。驗證日期是業務邏輯（我們正在驗證我們是適當的日期範圍，而不僅僅是日期是有效日期），所以我想知道是否選擇2）並將該業務邏輯從域模型中取出是錯誤的方法？您在回答問題時是否將業務邏輯視爲IsValidDate還是會影響您的答案？ – 2009-12-14 19:30:21

閱讀規範的DDD概念。規範是判斷一個對象是否滿足某個標準的謂詞。它現在是並且應該仍然是域模型的一部分，並且應該保留在模型中的域圖層中。 – 2009-12-14 20:13:01

如果你正在做簡單的is-this-actual-a-date字符串驗證，那麼在我看來，該方法的正確位置是在Service類中， Charles建議。然而，如果調整或調整集合對象內的數據可以改變日期驗證邏輯，例如，不允許某些日期範圍，該方法屬於該對象。

來源

2009-12-14 19:29:05 iandisme

我贊成第三種選擇，但是在調整時創建一個更通用的函數，如Validate（），它將返回一組錯誤/驗證錯誤。這樣，您可以在以後添加驗證規則而無需更改界面。 AdjustmentsGroup的Validate（）函數只需在集合中的每個成員上調用Validate（）。一個同樣有效的（不是雙關語意圖的）方式也可以爲包含所有驗證邏輯的對象具有單獨的驗證器類。

然後，您的AdjustmentService將在處理調整之前調用AdjustmentsGroup上的Validate（）。

來源

2009-12-14 19:29:10 ericvg

域模型中域對象的集合

回答

相關問題