关于ddd聚合根在实际应用中的意义。
0
悬赏园豆：10
[已解决问题]
解决于 2012-01-08 16:23
基础ddd的时间不太长，目前对聚合根有很多困惑，如图。
图中，Customer是一个聚合根，所以在ddd中，会只为Customer建立一个Repository。并且通过Customer来访问CreditCard。但是在一个系统中通常都会包括查询和业务处理。如果我们要查寻所有信用卡该如何处理？很明显CustomerRepository应该不会包含这个方法。如果脱离领域驱动，再专门建立一个查询系统，首先大大提高了系统的复杂度，其次如何应付查询后所进行的业务处理呢。
最佳答案
0
DDD正是针对你的业务流程来开发的，如果你把Customer作为根，那证明在业务调用上，每次都必须先获取Customer，再从其中获得CreditCard。
如果操作上需要单独对CreditCard进行修改，查询。那你就应该考虑把CreditCard独立成根聚合。
收获园豆：5
其他回答(1)
2
聚合的设计是根据业务的需要，是设计的结果！如你的例子那样，代表着业务逻辑中不会有单独对应信用卡的搜索需求，信用卡依附于Customer，由Customer控制信用卡的生命周期。
如果你的业务中允许信用卡脱离Customer单独存在，那么信用卡本身应该是一个聚合。但是实际业务中，脱离了Customer的信用开，貌似意义不大！
收获园豆：5
您好，感谢您的回答。
我的问题是，虽然在业务处理上，客户和信用卡作为一个聚合是合理的，但是我仍然会针对信用卡进行独立的查询。这是不可避免的。那么是否可以说因为我要对信用卡进行查询或分析，那么我就必须要把Customer和CreditCard拆分成两个独立的聚合根呢。
@Crisqiu: 也有相似的疑问。我换个角度提问：
- 查询类需求，是不是业务逻辑？
- 如果是，那么如何界定实现时：哪些步骤是数据逻辑，哪些步骤是业务逻辑？
- 领域模型是关注一个应用的所有业务逻辑，还是核心逻辑？
- 能否把查询类需求，视作一个一个外围的服务。在本例中，信用卡查询在自己所在的应用内，就可以称为聚合根？
- 如果以4的视角，考虑到这些外围服务各自的复杂性较低，便不必采用DDD，可以重用领域模型，也可以利用现有的repo，但其余的部分，在服务内部自行实现或扩展。针对这类项目，也不必按组件分层，项目内采用目录来区分职责是一种思路。最后，该服务的消费，交由应用层想表现层提供。
这样的话，一个聚合根可以作为另一个聚合根的非根聚合项？还是customer里只需要信用卡的ID就可以了，谢谢
