作为聚合根的地址?

为了区分地址是值对象还是实体,问自己一个问题——如果一个人的地址改变了,而第二个人的地址相同——两个人都会改变吗?如果它们都改变了-地址将被提升为实体(因为地址标识很重要而不是值)。

严格地说,这个聚合根不是必需的,但是如果我没有它,我将不得不遍历许多对象来获得完整的地址。基于该参数创建聚合根有意义吗?

不,没有。技术问题不应该影响你的领域。实体可以作为“子集合”,地址可以包含市政当局、城市等,但仍然只是一个实体(因为没有人是没有意义的)。

在这种情况下,用户只会引用聚合根目录,但是用户界面可能只显示市政当局(在浏览地址等时)。这是否违反了聚合根概念?

演示不应该与你的领域太乱。据我所知-如果只显示实体列表并隐藏它们所属的聚合,这是非常好的。

问题是-你想如何模拟移动过程?

1. 当人#1移动时,地址为 被改进的 但第二个人的地址不同,因此-不受影响。在本例中,address只是一个实体。
2. 当人#1移动时,移动过程

地址是独立存在的,如果一个人移动到一个地址,他就会与之关联。

记住,没有“模型”,只有“模型”。你不能模拟现实来完美地模仿它,你只能模拟它的一部分来模仿它 解决具体问题

这就是为什么很难回答ddd相关的问题。
没有人知道你要解决的问题。

http://msdn.microsoft.com/en-us/magazine/dd419654.aspx -关于聚合的部分,则一个地址是否可以没有人(或其他收件人)而存在是不相关的;问题是地址成分是否可以存在,或者在没有地址的情况下是否可以被访问。如果可以,地址不应该是聚合根。

这是相关的。如果地址离不开人(这里不是这样),它就不可避免地被降级为实体(因为没有人它就没有意义)或价值对象(如果地址本身没有身份)。否则,只会引入不必要的聚合根。

在我看来,如果

1. 有一个围堵 物体
2. 物体 聚合存储在数据库中, 只有根应该是 可通过查询获得。这个 通过遍历关联。

你的场景似乎不满足这两个。所以我的意见是否定的

同时阅读这篇文章并提供答案: DDD: Aggregate Roots

你谈论地址的方式告诉我它是一个独立的实体,由你提到的组成部分组成。

即使地址与某个人或另一个类没有关联,它仍然存在,这一事实也表明它应该是自己的实体。

仅仅是把地址作为一个特定的概念来讨论这个事实就足以使它成为一个单独的类。即使在地址只存在于另一个类的情况下,创建一个单独的类(在这种情况下可能是嵌套类)也是有意义的,只要将处理地址的逻辑与处理其他人属性的逻辑分开。

更新

http://msdn.microsoft.com/en-us/magazine/dd419654.aspx -关于聚合的部分,则一个地址是否可以没有人(或其他收件人)而存在是不相关的;问题是地址成分是否可以存在,或者在没有地址的情况下是否可以被访问。如果可以,地址不应该是聚合根。

一方面,地址应该是其组成部分的集合。但是,地址的组成部分似乎独立于地址,没有地址也可以存在。毕竟,一个市镇或一条街道可以在没有“门”的情况下存在。所以,我想说,这取消了地址作为DDD术语的聚合根的资格。

更新

我认为,从一个列表中选择一个市政当局来构建一个地址并不是“直接操纵”,因为它总是在构建地址的上下文中进行的。同样地,我也不会考虑保留一份市政当局“直接操纵”名单,如果它只供一个地址使用的话。

正如阿尼斯所指出的,地址是否可以独立于人(或另一个实体)而存在,这与地址本身是否是一个实体有关。我现在的理解是,只有实体才能是聚合根。