DDD - 從實體中派生價值對象

Question

我對DDD非常陌生，並且一如既往，當您將自己的頭圍繞在有趣的概念中時，您將不可避免地觸及到某個點或某種情況，這會讓您不確定如何隨之產生的結果學會應該面對某些問題應用。

假設您有兩個關於用戶的不同日期：DateOfBirth和DateOfRegistration。將它們分別作爲兩個不同的值來實現是非常有意義的。這很簡單，很棒。

現在，我們假設在一個應用程序Users可以參與Projects。一個項目可以有多個members和一個創建（擁有）它的用戶。

因此ProjectMembers和ProjectOwner都是Users。

有兩種方式Project來實現這個功能：

答：強類型 - 創建類ProjectMember和ProjectOwner然後「行爲」的值對象。要麼讓他們作爲包裝工作，要麼甚至擴展User類。

B：懶惰的方法 - 根據期望的行爲/期望簡單地命名方法和參數，並推動User周圍的對象。

在我看來，以下B意味着滴DDD的原則。

以下A會導致數十個班級，其中許多班級不會做任何事情，但會強制執行類型安全。

我很困惑，因爲與簡單的日期相比，用戶是實體甚至聚合根，同時更復雜。

是A，B還是有第三種選擇？

Answer 1

以下A會導致數十個班級，其中許多班級不會做任何事情，但會強制執行類型安全。

不，他們還記錄了您在域模型中發現的區別;你可能還不知道這些區別是如何影響模型的行爲的，但是你已經掌握了佔位符和正確的語言（假設你的名字正在繪製無處不在的語言），所以你的領域模型更接近對齊與業務。

那不是什麼。

我很困惑，因爲與簡單的日期相比，用戶是實體甚至聚合根，同時也更復雜。

因此，有一點需要記住 - 您不會像習慣一樣，從保護他們的聚合體之外引用實體。所以ProjectOwnerId而不是ProjectOwner。

對於類型不做什麼有趣的事（標識尤其趨於是沒有做太多，除了比其他標識符不透明的事），你 可能會有點語法使用相同類型確保型糖安全。

例如Identifier<T>給你Identifier<ProjectMember>和Identifier<ProjectOwner>含蓄，而不是要求你產生不同的實現方式爲標識符

的每個拼寫