【问题标题】:Having id-field on a value object in DDD在 DDD 中的值对象上具有 id 字段
【发布时间】:2016-02-24 15:13:30
【问题描述】:

我正在做一个项目,我在聚合中有一个值对象(称为SkillProfile)。聚合根是User 实体,User 与其SkillProfile 具有单向的一对一关联。在业务中有一个用例,SkillProfile 可以与另一个User 共享,但始终作为副本(因此修改其中一个配置文件不会更改任何其他用户配置文件)。到目前为止一切顺利。

现在企业有了新的要求,应该可以在报告中看到哪些用户共享相同的技能配置文件。技能配置文件上的 equals 方法无法满足此要求,因为有些技能配置文件巧合地具有相同的值,但在明确执行时并未“共享”。当然,技能配置文件必须不可变的旧要求仍然有效。

所以我的问题是:在SkillProfile 类上发明一个新字段“Id”或“SharingCode”是否是个好主意,因此给它某种身份,尽管它仍然是一个值对象而不是一个实体,因为它没有状态或生命周期?

【问题讨论】:

  • 我觉得你说的已经不是价值对象了。如果它必须是可识别的,那么它就是一个实体。另一种选择可能是使用聚合(用户)ID 来识别技能配置文件的来源,但我不深入了解您的领域,所以我不确定它是否可以工作。

标签: domain-driven-design value-objects


【解决方案1】:

首先,

因此修改其中一个配置文件不会更改任何其他用户的配置文件

如果SkillProfile 确实是一个值对象,那么应该不可能修改一个!在User 中替换它当然可以。 (只是在讨论您的问题之前明确这一点)


根据新要求,SkillProfile 需要一个身份 - 无论是显式的还是隐式的 - 因为不再仅通过查看其值来比较它。 因此,它现在是一个实体。

请注意,您无需将其与之前的值对象区别对待 - 例如,保持实体不可变是个好主意,因为这仍然是概念的本质。 所以让它成为一个实体应该不是很大的一步。

【讨论】:

  • 你是对的,修改是错误的术语。我实际修改的意思是更改 Users SkillProfile 属性。当然,这将通过用新值对象替换旧值对象来完成。我同意将 SkillProfile 从值对象更改为实体。现在聚合根必须确保技能配置文件将被新身份替换。
  • @Dominik 业务需求的变化会引起领域模型的变化。这没有什么问题......
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2014-06-03
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2021-09-21
  • 1970-01-01
  • 2012-07-13
相关资源
最近更新 更多