聚合根相关理解,这样对吗?

1. 一个“上下文” 可以包含多个聚合边界
2. 一个聚合边界里面只包含一个聚合根和多个实体或者值对象
3. 在一个“上下文”中的某个聚合内的实体也可以被另外一个“上下文”中的聚合根或者实体引用, 但不能被同一个“上下文”中的其他聚合根或实体引用

4. 关于聚合根标识和实体标识, 聚合根标识是全局和实体标识是本地, 实体标识之所以为本地,是因为在当前“上下文”对这个实体的访问必须通过聚合根, 因此它的标识作为全局是没有意义的, 但可能在另外的“上下文”中它成为了聚合根,因此在实际设计时,它依然有ID 作为全局标识

一直对聚合根概念很模糊,很多问题都没澄清过,看到这里有人讨论这些问题,希望有人帮忙解惑
[该贴被pojia于2013-01-13 01:15修改过]

发现聚合及其聚合根是一个创造性过程,因此如果遵守太多条条框框会制约创造性。将能力当成知识无疑变得保守。

第2个问题显然是错误的,DDD书籍中Car和Enginee都是聚合根,见下图:

第3个问题是将上下文Context权威化,实际是将变化高于结构性本质,当然在具体处理上也违反OO,一个聚合边界代表一个大比例对象,试验想想用Scala的Akka实现,Actor代表一个聚合根,Actor之间使用异步消息实现调用,而不是结构上相互引用,相互引用是DDD中最排斥的一种做法,能不关联就不要关联,除非是高度聚合关系。

第4个问题我认为也值得讨论,聚合根实际是一个实体,也就是实体担任聚合根这个角色,就如同北京是国家首都,首都只是其一个角色而已,比如组长只是组这个聚合边界内的职责而已,聚合根和实体是合二为一的。

如果聚合根标识和实体标识不同,那么无疑来了两个标识,标识增加无疑添加系统的复杂性。

这些观点中,强调上下文对聚合根的影响,我认为还是因为考虑到使用传统OO方式来实现DDD,必然碰到一些问题,只能用打折扣的方式人为增加一些规则。

上下文代表一种临时细节,而聚合代表一种宏观高度,如果不能确定好它们主次关系,必然DDD的分析方法会走上畸形。



[该贴被banq于2013-01-13 10:34修改过]


对于Car和Engine 的例子,我理解为两个聚合
1. Car 和Engine,Wheel,Tire,Position 组成一个聚合, Car 为聚合根,Engine在这个聚合里扮演实体角色
2. Engine 是一个聚合,自己扮演聚合根

这里我理解为有两个聚合边界对应两个聚合根,,而不是一个聚合边界对于两个聚合根
[该贴被pojia于2013-01-13 14:23修改过]

2013-01-13 01:11 "@pojia"的内容
1. 一个“上下文” 可以包含多个聚合边界
2. 一个聚合边界里面只包含一个聚合根和多个实体或者值对象
3. 在一个“上下文”中的某个聚合内的实体也可以被另外一个“上下文”中的聚合根或者实体引用, 但不能被同一个“上下文”中的其他聚合根 ...

1. 正确
2. 正确
3. 不正确,外部对象只能持有根实体
4. 不正确,一个实体如果不是聚合根,就永远不是,与上下文没有关系,就算到这个上下文中是聚合根了,那也是另外一个对象,不是同一个对象类,实体的ID可以是全局唯一,也可以是局布唯一,重要的是要符合高内聚