首页 新闻 赞助 找找看

关于ddd聚合根在实际应用中的意义。

0
悬赏园豆:10 [已解决问题] 解决于 2012-01-08 16:23

基础ddd的时间不太长,目前对聚合根有很多困惑,如图。

图中,Customer是一个聚合根,所以在ddd中,会只为Customer建立一个Repository。并且通过Customer来访问CreditCard。但是在一个系统中通常都会包括查询和业务处理。如果我们要查寻所有信用卡该如何处理?很明显CustomerRepository应该不会包含这个方法。如果脱离领域驱动,再专门建立一个查询系统,首先大大提高了系统的复杂度,其次如何应付查询后所进行的业务处理呢。

Crisqiu的主页 Crisqiu | 初学一级 | 园豆:183
提问于:2011-10-18 10:37
< >
分享
最佳答案
0

DDD正是针对你的业务流程来开发的,如果你把Customer作为根,那证明在业务调用上,每次都必须先获取Customer,再从其中获得CreditCard。

如果操作上需要单独对CreditCard进行修改,查询。那你就应该考虑把CreditCard独立成根聚合。

收获园豆:5
风尘浪子 | 菜鸟二级 |园豆:422 | 2012-01-06 21:25
其他回答(1)
2

聚合的设计是根据业务的需要,是设计的结果!如你的例子那样,代表着业务逻辑中不会有单独对应信用卡的搜索需求,信用卡依附于Customer,由Customer控制信用卡的生命周期。

如果你的业务中允许信用卡脱离Customer单独存在,那么信用卡本身应该是一个聚合。但是实际业务中,脱离了Customer的信用开,貌似意义不大!

收获园豆:5
basicArchitecter | 园豆:162 (初学一级) | 2011-10-18 11:34

您好,感谢您的回答。

我的问题是,虽然在业务处理上,客户和信用卡作为一个聚合是合理的,但是我仍然会针对信用卡进行独立的查询。这是不可避免的。那么是否可以说因为我要对信用卡进行查询或分析,那么我就必须要把Customer和CreditCard拆分成两个独立的聚合根呢。

支持(1) 反对(0) Crisqiu | 园豆:183 (初学一级) | 2011-10-18 13:17

@Crisqiu: 也有相似的疑问。我换个角度提问:

  1. 查询类需求,是不是业务逻辑?
  2. 如果是,那么如何界定实现时:哪些步骤是数据逻辑,哪些步骤是业务逻辑?
  3. 领域模型是关注一个应用的所有业务逻辑,还是核心逻辑?
  4. 能否把查询类需求,视作一个一个外围的服务。在本例中,信用卡查询在自己所在的应用内,就可以称为聚合根?
  5. 如果以4的视角,考虑到这些外围服务各自的复杂性较低,便不必采用DDD,可以重用领域模型,也可以利用现有的repo,但其余的部分,在服务内部自行实现或扩展。针对这类项目,也不必按组件分层,项目内采用目录来区分职责是一种思路。最后,该服务的消费,交由应用层想表现层提供。
支持(1) 反对(0) sinlight23 | 园豆:222 (菜鸟二级) | 2013-02-08 11:26

这样的话,一个聚合根可以作为另一个聚合根的非根聚合项?还是customer里只需要信用卡的ID就可以了,谢谢

支持(0) 反对(0) 会长 | 园豆:12384 (专家六级) | 2018-01-26 21:24
清除回答草稿
   您需要登录以后才能回答,未注册用户请先注册