看了《ImplDDD》感觉又回到了原点,困惑!

13-06-23 21022102
1.ProductId, BacklogId 之类的“值对象”真的有必要存在,为什么?明明只是一些简单的id,非要变成各种所谓的VO,到底是为哪样?让UML看起来更像“聚合”?

2.“小聚合” 、“按id引用”,真的那么合理?发现很多讨论DDD的地方,一旦有Collection,“毫无疑问,你错了,他应该是一个独立聚合根,... ...”,为什么按这些指导思想,感觉最终回到了以table为单位来设计了?多对多关系怎么表达?

3.按照小聚合的思想,基本上一个聚合就一个Entity,其他所谓VO基本就是些xxxID,这样的聚合有什么意义?如果这样,抛弃聚合的概念,每个Entity不是照样可以维护一致性么?

banq
2013-06-24 10:10
我认为你的疑惑有道理。

虽然值对象都是由值组成的对象,但是在DDD原文中值对象的定义是从业务角度定义的,落实成代码也许是一些ID和一些初始类型,但这些是结果,是人拉的屎,不能根据结果来决定其构成原因。将id和值对象进行混合,是容易引起数据表的联想,“按id引用”, 其实已经破坏了对象的封装,让人产生误导。

什么是聚合 ,什么实体,还是要按照DDD原文定义来,被其解释后反而容易走偏。

[该贴被banq于2013-06-24 10:14修改过]

21022102
2013-06-24 13:50
2013-06-24 10:10 "@banq
"的内容
我认为你的疑惑有道理。
...


“以领域为中心”,“通用语言”,“聚合”这些思想是很好的,可是实现起来就完全变形了。从这些“work-around"来看,我感觉DDD不流行,很大程度上还是技术原因,甚至CQRS也只是向技术妥协的产物。反正没有比ActiveRecord强到哪去。

banq
2013-06-25 08:32
2013-06-24 13:50 "@21022102
"的内容
甚至CQRS也只是向技术妥协的产物。反正没有比ActiveRecord强到哪去。 ...


如果抱着ActiveRecord这些ORM思维去解放领域模型确实很难,见这篇文章:http://www.jdon.com/43937

clonalman
2013-06-30 19:56
2013-06-24 13:50 "@21022102
"的内容
感觉DDD不流行,很大程度上还是技术原因,甚至CQRS也只是向技术妥协的产物。反正没有比ActiveRecord强到哪去。 ...


CQRS的出发点是好的,只是在技术实现上把领域模型绑架了,就像ORM绑架领域模型一样.

ActiveRecord能够得到很好的对象模型,但也是一样被技术所绑架,ActiveRecord对象自身的CRUD功能,使其与之关联的对象不可能存在领域上的“聚合”关系,与DDD相比,实质是对象模型描述现实模型强弱问题

SpeedVan
2013-07-12 18:27
对于值对象,请看我对值对象的理解,现阶段我有更深理解,但那时的理解没有偏差。

小聚合,我没有那概念,那是别人一些经验推荐,要怎么想自己考虑,原DDD也没这样的要求。

原来的Entity是不能维护一致性的,当Entity相互独立时,假若一个EntityA拥有另外一个EntityB的值时,一致性就开始崩溃,这很大程度是归于set的问题。让Entity不相互独立,例如EntityA内聚EntityB,让对B所有能引起状态变化的修改都必须通过A,那么一致性问题就能解决。当然这是你需要一致性的时候才使用,这并不是乱内聚的。

关于ID引用问题,请说出不合理的原因,再作讨论,没有环境直接谈合理与否,就像没有范围谈真理一样无聊。

[该贴被SpeedVan于2013-07-12 18:32修改过]