nhibernate - DDD : Should everything fit into either Entity or Value Object?

Question

我正在尝试遵循 DDD，或者至少是我对它的有限理解。

不过，我在将一些东西装入 DDD 盒子时遇到了麻烦。

一个例子:我有一个用户实体。这个用户实体有一个对 UserPreferencesInfo 对象的引用 - 这只是一个包含一堆关于用户首选项的属性的类。这些属性是相当不相关的，除了它们都是用户偏好的事实(不像地址 VO，其中所有属性形成一个有意义的整体)。

问题是 - 这个 UserPreferencesInfo 对象是什么？

1)显然它不是实体(我只是将它存储为流利的 nhibernate 语言中的“组件”(即与用户实体在同一个数据库表中)。

2)VO？我知道值对象应该是不可变的(所以你不能改变它们，只需将它们更新)。例如，当对象是一个地址时(地址属性形成一个有意义的“整体”)，这完全有意义。但在 UserPreferencesInfo 的情况下，我认为这没有意义。可能有 100 个属性(实际上)这个对象上可能有 20 个属性 - 为什么我要在需要更改一个属性时丢弃重新创建的对象？

我觉得我需要在这里打破规则才能得到我需要的东西，但我真的不喜欢这个想法(这是一个滑坡!)。我在这里错过了什么吗？

谢谢

Answer 1

答案1(实用的)

我是 DDD 的大力支持者，但不要强制它。您已经认识到，不可变的 VO 增加的工作量超出了要求。 DDD 旨在利用复杂性，但在这种情况下，管理的复杂性非常低。

我会简单地对待 UserPreferencesInfo作为 实体 ，并从 User 中引用它总计的。是将其存储为组件还是单独的表是您的选择。

恕我直言，整个 Entity 与 VO 的辩论都没有实际意义。极不可能在 6 个月内，另一位开发人员会查看您的代码并说“WTF!他没有使用不可变的 VO!他到底在想什么!!”。

答案 2(DDD 纯粹主义者)

是 UserPreferencesInfo实际上是业务领域的一部分？其他人提到解剖这个对象。但是如果你坚持纯 DDD，你可能需要确定哪些偏好属于哪些 有界上下文 .

这反过来可能导致添加 服务层 ，在不知不觉中，您已经为一个非常简单的问题过度设计了解决方案......