发帖    主题    评论    推荐    标签    作者    订阅    查搜    注册   登陆   关注
 
面向对象 设计模式 领域驱动设计 企业架构 框架 开发教程 微服务 CQRS 扩展性 并发编程 事件溯源 分布式 SOA
1 2 下一页 Go 2

聚合根的一点疑问

         
2013-12-06 14:29
赞助商链接

举个例子,一个交易系统:用户购买某个商品生成一笔交易
可以抽象出,聚合根:交易,用户和商品是交易的属性
那用户这个对象 那就不是聚合根,而是值对象?
随着业务的发展,比如根据交易衍生出等级会员制度,那用户是不是也会变成一个聚合根
CQRS中读缓存是缓存整个领域对象还是缓存值对象?
缓存领域对象,数据的一致性挺难保证的
领域层中说的领域对象指的是聚合根还是所有的对象?

[该贴被tecentIDA8F53于2013-12-06 14:30修改过]

2013-12-06 15:13


2013-12-06 14:29 "@
tecentIDA8F53"的内容
那用户这个对象 那就不是聚合根,而是值对象?
随着业务的发展,比如根据交易衍生出等级会员制度,那用户是不是也会变成一个聚合根 ...


聚合根与上下文场景是有关的,比如我们说北京是首都,它是指中国的首都,是中国这个边界上下文的聚合根,中国在我们谈话表达时是隐藏的一个定义,因为别人不会认为北京是日本的首都。

所以,提取聚合根,首先是找出上下文边界,中国和日本至少要划清边界,现在航空识别区也是在干这事,但是很不容易,最难的。

分析需求也是这样,找出上下文边界是最难,找到了,聚合根也就找到了。

你这个案例将两个上下文场景混同在一起,一个是用户交易场景,一个是用户会员等级场景。

2013-12-06 16:08


2013-12-06 15:13 "@
banq"的内容
用 ...

那两个业务都需要有user这个属性,@banq 您的意思是user这个对象只能存在于一个聚合根中?当业务发展衍生出新的聚合根,那边界就需要重新划分?比如上面例子的user就只能存在于会员聚合根,交易需要用户信息需要请求会员聚合根给他?

2013-12-06 16:29


2013-12-06 15:13 "@
banq"的内容
分析需求也是这样,找出上下文边界是最难,找到了,聚合根也就找到了。 ...

而且这个边界 随着业务发展也会不断的变化,比如有一天中国吞并日本,抑或是日本分为南日和北日,那这时候不是基本要推到原来的设计

2013-12-12 01:15

发现前两天还是脑子没转过来,现在终于有一点点想明白聚合根的意义了,其实聚合根是职责的划分,也有点类似以前的模块的说法,上面的场景交易如果需要会员信息,应该是找用户聚合根要,而不是自己去拿。领域对象的难点在于聚合根的提炼过程

2Go 1 2 下一页

赞助商链接

赞助商链接

返回顶部

移动版 关于本站 使用帮助 联系反馈 最佳分辨率1366x768
OpenSource JIVEJDON Powered by JdonFramework Code © 2002-20 jdon.com