【发布时间】:2016-02-24 15:13:30
【问题描述】:
我正在做一个项目,我在聚合中有一个值对象(称为SkillProfile)。聚合根是User 实体,User 与其SkillProfile 具有单向的一对一关联。在业务中有一个用例,SkillProfile 可以与另一个User 共享,但始终作为副本(因此修改其中一个配置文件不会更改任何其他用户配置文件)。到目前为止一切顺利。
现在企业有了新的要求,应该可以在报告中看到哪些用户共享相同的技能配置文件。技能配置文件上的 equals 方法无法满足此要求,因为有些技能配置文件巧合地具有相同的值,但在明确执行时并未“共享”。当然,技能配置文件必须不可变的旧要求仍然有效。
所以我的问题是:在SkillProfile 类上发明一个新字段“Id”或“SharingCode”是否是个好主意,因此给它某种身份,尽管它仍然是一个值对象而不是一个实体,因为它没有状态或生命周期?
【问题讨论】:
-
我觉得你说的已经不是价值对象了。如果它必须是可识别的,那么它就是一个实体。另一种选择可能是使用聚合(用户)ID 来识别技能配置文件的来源,但我不深入了解您的领域,所以我不确定它是否可以工作。
标签: domain-driven-design value-objects