DDD中的值對象上有id字段

我正在處理一個項目，其中有一個聚合內的值對象（稱爲SkillProfile）。彙總根目錄是User實體，User與它的SkillProfile具有單向一對一關聯。業務中有一個使用案例，SkillProfile可以與另一個User共享，但始終作爲副本（因此修改其中一個配置文件不會更改任何其他用戶配置文件）。到現在爲止還挺好。DDD中的值對象上有id字段

現在企業有了新的要求，應該可以在報告中看到哪些用戶共享相同的技能檔案。這項要求不能通過技能檔案中的等同方法來實現，因爲技能檔案巧合地具有相同的值，但在明確地執行時並不「共享」。當然，技能配置文件必須是不可變的舊要求仍然有效。

所以在這裏我的問題：在SkillProfile類上發明一個新字段「Id」或「SharingCode」是否是一個好主意，因此給它一些類型的身份，儘管它仍然是一個值對象而不是實體，因爲它沒有狀態或生命週期？

來源

2015-11-22 Dominik

我認爲你所說的不再是價值對象。如果它必須是可識別的，那麼它是一個實體。另一種選擇可能是使用聚合（用戶）ID來識別技能配置文件的來源，但我不深入理解您的域，所以我不確定它是否可行。 – inf3rno

首先，

所以修改配置文件中的一個將不會改變任何其他用戶的個人資料

如果SkillProfile確實是一個值對象，應該是沒有可能改變一個！在User內替換它當然沒有問題。（只是有討論你的問題之前，這清楚）

有了新的要求，需要SkillProfile一個身份 - 無論明示或暗示的 - 因爲它不再能夠通過看它的值進行比較。 因此，它現在是一個實體。

請注意，您不需要對它的處理方式與之前的值對象不同 - 例如，讓實體不可變是個不錯的主意，因爲這仍然是概念的本質。所以它不應該是一個很大的一步，使其成爲一個實體。

來源

2015-11-24 06:21:55 theDmi

你說得對，修改是錯誤的。我修改的意思是改變用戶的SkillProfile屬性。當然，這將通過用新的值替換舊的值對象來完成。我同意將價值對象的SkillProfile更改爲實體。現在，根集合必須確保將技能配置文件替換爲新的身份。 – Dominik

@Dominik業務需求的變化可能導致領域模型的變化。沒有什麼不妥... – inf3rno

DDD中的值對象上有id字段

回答

相關問題