聚合根的一点疑问

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

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


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

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

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

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

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


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

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


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

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

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


2013-12-12 01:15 "@
tecentIDA8F53"的内容
领域对象的难点在于聚合根的提炼过程 ...

顿悟得很正确,职责 模块 上下文都是一个思路方向的不同用词。

我觉得首先分析并确立出上下文,基于上下文来建模出我们的领域对象/聚合,上下文可能会有所修改(增加,变动),但是这种变动应该也是有界的,如果我们变动的级别达到了需要重新分析上下文,重新建立领域模型的话,这更像是另外一个全新的业务,而不仅仅是一个修改。