关于DDD,DDD聚合根的一些问题

最近研究DDD开发,遇到一些问题,忘大虾指点,不要只限与概念,最好能有个具体Solution

1.实际项目中许多Entity都引用了User,以往开发的时候,我都只是做了UserID属性来隐含关联。如果有需求对Entity引用的User通过DisplayName排序,这个时候不得不用到Left Join,最近用ORM框架,如果实现上面的需求,需要在Entity中显示的引用User,这样才能自动生成Navigation查询。想问下,对于User这种Entity,在整个项目中会有太多的引用,并需要做这种排序,如何处理?

2.看到大家问了好久的聚合根问题,我也是模糊的。还是如帖子和回复的问题,个人处理还是会把帖子和回复都作为聚合根。因为这里面常有的操作就是对回复的编辑和删除,虽然编辑回复的时候是需要影响到帖子的,但Repository里应该是得到聚合根,而不是聚合根下的实体。那我们得到回复,就只能通过回复ID的所属帖子,再从帖子里找到回复,在这就晕了。不要去考虑 In Memory,技术总没底线,我们只要实现目前。大家都怎么处理的?帮忙开拓下

2011年12月13日 23:39 "@lyk831216"的内容
如果有需求对Entity引用的User通过DisplayName排序, ...

这是查询功能,有两种解决方法:
1.通过Respository实现排序查询,不必一定在实体中加关联
2.排序属于读操作,按照CQRS架构,读操作和写操作分离,领域实体是专门为写操作设计的。

DDD设计原则是低关联 高聚合,能不用关联尽量不用,如果不用关联实体就不能代表那个实体了,就需要高聚合的关联。比如玻璃是窗子组成部分,没有玻璃这个关联,窗子就不是窗子。

用户这个对象更加特殊,最多只能作为值对象被引用在实体中,用户与角色 DCI这些概念有关,本站之前有大量讨论,可参考。

谢谢,CQRS现在研究,项目来不及了,找一些折中办法了