开始看infoq的mini book时，我以为这不是个问题。Entity就是有主键的对象，Value Object就是immutable class， so easy.

然后就越看越糊涂了。糊涂在于Value Object究竟是个什么东西：按书中所说，Value Object最好是immutable class， 但在某些情况下，比如修改非常频繁，或者创建/删除对象代价很大，也允许mutability。那么，一个mutable Value Object和Entity 对于使用者又有什么区别呢？

如果Entity和Value object区别在于mutability上，使用者只要看看这个class是否implements Entity/ValueObject interface，就知道是否要对修改作同步，是否可以共享。但若mutability只是Value Object的一个可选项，即使给我一个Value Object，我又怎敢放心传出引用而不加同步呢？或者说我应该去看Javadoc，去看API，那么就回到jdk的状态了：只有通过非code的渠道才能知道String/boxing class是immutable class，而没法在code中显示标记出这个事实。

既然如此，Entity 和Value Object这两者根本就不要区分了嘛。对于domain object, interface虽然比parant class要轻很多，但比annotation还是要重，搞两个interface出来却不能带出更好的先验知识，还不如直接用个Imutable的annotation来的好（当然,Java还没强到能够用一个annotation直接把一个类给lock了，我只是假设如果有这个能力的话）， 或者干脆不要区分这两个东西来得简单。

另一个角度来看这个问题， ddd sample中，Entity需要实现sameIdentityAs方法，ValueObject需要实现sameValueAs方法，我觉得没必要。equals方法的设计初衷就是表示两个Object是否相等，至于用PK比较还是用attributes比较，是每个class自己的责任，没必要画蛇添足的再分成两个方法吧。实际上, ddd sample的实现中也是让equals调用sameIdentityAs和sameValueAs。我没看到什么地方时equals做不到而那两个方法能作到的，既然如此，根据KISS原则，这两个function就没有存在的价值了。

所以，如果认为Value Object也可以不是immutable，那么区分Entity和Value Object既没有名字上的意义（不能从名字上获得简单直接的信息），也没有方法签名上的差距（实际上这两个接口都应该是dume interface），也就没有区别存在了。所以，论坛上那么多人讨论 XXX是Entity还是Value Object应该换个问法: XXX是不是该作成immutable class？

这个问题我想了挺多天了，和aggregate root的效率一样（下面会写到），是我最不能理解的两个问题。目前的理解就是这样，好像还不是很清楚，再想想吧。

我