1.ProductId, BacklogId 之类的“值对象”真的有必要存在,为什么？明明只是一些简单的id，非要变成各种所谓的VO，到底是为哪样？让UML看起来更像“聚合”？
2.“小聚合” 、“按id引用”，真的那么合理？发现很多讨论ddd的地方，一旦有Collection，“毫无疑问，你错了，他应该是一个独立聚合根，... ...”，为什么按这些指导思想，感觉最终回到了以table为单位来设计了？多对多关系怎么表达？
3.按照小聚合的思想，基本上一个聚合就一个Entity，其他所谓VO基本就是些xxxID，这样的聚合有什么意义？如果这样，抛弃聚合的概念，每个Entity不是照样可以维护一致性么？
我认为你的疑惑有道理。
虽然值对象都是由值组成的对象，但是在DDD原文中值对象的定义是从业务角度定义的，落实成代码也许是一些ID和一些初始类型，但这些是结果，是人拉的屎，不能根据结果来决定其构成原因。将id和值对象进行混合，是容易引起数据表的联想，“按id引用”， 其实已经破坏了对象的封装，让人产生误导。
什么是聚合 ，什么实体，还是要按照DDD原文定义来，被其解释后反而容易走偏。
[该贴被banq于2013-06-24 10:14修改过]
“以领域为中心”，“通用语言”，“聚合”这些思想是很好的，可是实现起来就完全变形了。从这些“work-around"来看,我感觉DDD不流行，很大程度上还是技术原因，甚至CQRS也只是向技术妥协的产物。反正没有比ActiveRecord强到哪去。
如果抱着ActiveRecord这些ORM思维去解放领域模型确实很难，见这篇文章：http://www.jdon.com/43937
CQRS的出发点是好的,只是在技术实现上把领域模型绑架了,就像ORM绑架领域模型一样.
ActiveRecord能够得到很好的对象模型，但也是一样被技术所绑架，ActiveRecord对象自身的CRUD功能，使其与之关联的对象不可能存在领域上的“聚合”关系，与DDD相比，实质是对象模型描述现实模型强弱问题
对于值对象，请看我对值对象的理解，现阶段我有更深理解，但那时的理解没有偏差。
小聚合，我没有那概念，那是别人一些经验推荐，要怎么想自己考虑，原DDD也没这样的要求。
原来的Entity是不能维护一致性的，当Entity相互独立时，假若一个EntityA拥有另外一个EntityB的值时，一致性就开始崩溃，这很大程度是归于set的问题。让Entity不相互独立，例如EntityA内聚EntityB，让对B所有能引起状态变化的修改都必须通过A，那么一致性问题就能解决。当然这是你需要一致性的时候才使用，这并不是乱内聚的。
关于ID引用问题，请说出不合理的原因，再作讨论，没有环境直接谈合理与否，就像没有范围谈真理一样无聊。
[该贴被SpeedVan于2013-07-12 18:32修改过]