Domain driven design 在DDD中的值对象上具有id字段

我正在从事一个项目，在该项目中，我在聚合中有一个值对象（称为

SkillProfile

）。聚合根是

用户

实体，

用户

与其

技能档案

具有单向一对一关联。业务中存在这样的用例，即

SkillProfile

可以与另一个

用户

共享，但始终作为副本（因此修改一个配置文件不会更改任何其他用户配置文件）。到目前为止还不错

现在，企业有了一个新的要求，即应该能够在报告中看到哪些用户共享相同的技能配置文件。这一要求不能通过技能配置文件上的equals方法来满足，因为有些技能配置文件碰巧具有相同的值，但在显式执行时没有“共享”。当然，技能档案必须是不变的这一旧要求仍然有效

因此，我的问题是：在

SkillProfile

类上创建一个新字段“Id”或“SharingCode”是否是一个好主意，并因此赋予它某种身份，尽管它仍然是一个值对象，而不是实体，因为它没有状态或生命周期

因此，修改一个配置文件不会改变其他任何用户配置文件

如果

SkillProfile

确实是一个值对象，则不可能修改它！在

用户

中替换它当然可以。（只是为了在讨论你的问题之前弄清楚）

---

在新的需求中，

SkillProfile

需要一个标识——无论是显式的还是隐式的——因为它不再能够仅仅通过查看它的值来进行比较因此，它现在是一个实体。

---

请注意，您不需要将其与以前的值对象区别对待—例如，保持实体不变是一个好主意，因为这仍然是概念的本质。因此，将其变为实体不应该是一个很大的步骤。

我认为您所谈论的不再是值对象。如果它必须是可识别的，那么它就是一个实体。另一种选择是使用聚合（用户）id来标识技能配置文件的来源，但我不太了解您的领域，因此我不确定它是否有效。您是对的，修改是一个错误的术语。我修改的真正意思是更改

User

s

SkillProfile

属性。当然，这可以通过用新的值对象替换旧的值对象来实现。我同意将SkillProfile从值对象更改为实体。现在，聚合根用户必须确保技能配置文件将替换为新标识。@Dominik业务需求的更改可能会导致域模型的更改。这没什么错。。。