聚合根的一点疑问
举个例子,一个交易系统:用户购买某个商品生成一笔交易
可以抽象出,聚合根:交易,用户和商品是交易的属性
那用户这个对象 那就不是聚合根,而是值对象?
随着业务的发展,比如根据交易衍生出等级会员制度,那用户是不是也会变成一个聚合根
CQRS中读缓存是缓存整个领域对象还是缓存值对象?
缓存领域对象,数据的一致性挺难保证的
领域层中说的领域对象指的是聚合根还是所有的对象?
[该贴被tecentIDA8F53于2013-12-06 14:30修改过]
举个例子,一个交易系统:用户购买某个商品生成一笔交易
可以抽象出,聚合根:交易,用户和商品是交易的属性
那用户这个对象 那就不是聚合根,而是值对象?
随着业务的发展,比如根据交易衍生出等级会员制度,那用户是不是也会变成一个聚合根
CQRS中读缓存是缓存整个领域对象还是缓存值对象?
缓存领域对象,数据的一致性挺难保证的
领域层中说的领域对象指的是聚合根还是所有的对象?
[该贴被tecentIDA8F53于2013-12-06 14:30修改过]
聚合根与上下文场景是有关的,比如我们说北京是首都,它是指中国的首都,是中国这个边界上下文的聚合根,中国在我们谈话表达时是隐藏的一个定义,因为别人不会认为北京是日本的首都。
所以,提取聚合根,首先是找出上下文边界,中国和日本至少要划清边界,现在航空识别区也是在干这事,但是很不容易,最难的。
分析需求也是这样,找出上下文边界是最难,找到了,聚合根也就找到了。
你这个案例将两个上下文场景混同在一起,一个是用户交易场景,一个是用户会员等级场景。
发现前两天还是脑子没转过来,现在终于有一点点想明白聚合根的意义了,其实聚合根是职责的划分,也有点类似以前的模块的说法,上面的场景交易如果需要会员信息,应该是找用户聚合根要,而不是自己去拿。领域对象的难点在于聚合根的提炼过程
顿悟得很正确,职责 模块 上下文都是一个思路方向的不同用词。
我觉得首先分析并确立出上下文,基于上下文来建模出我们的领域对象/聚合,上下文可能会有所修改(增加,变动),但是这种变动应该也是有界的,如果我们变动的级别达到了需要重新分析上下文,重新建立领域模型的话,这更像是另外一个全新的业务,而不仅仅是一个修改。