对象贫血一定是错的么？还是DDD领域驱动设计有误区？

领域驱动设计中有一个概念叫“贫血对象”，指那些只包含set和get方法、仅仅用来保存和传递数据的对象。
例如：一个Customer对象，不能只有setLocation和getLocation方法，在客户搬家时应该不仅仅是用setLocation直接赋予一个新的地址，而是用moveTo方法来包含处理客户搬家的逻辑。

乍一看很有道理，仔细想有问题！
设想有一个桶，我可以用来装水，在我儿子眼里套在头上是个头盔。如果我把“装水”这个方法定义在桶这个对象里，我儿子又把“戴头上”这个方法定义在桶上，哪天我儿子把这个桶当凳子坐的时候，又会影响到我！

为什么某些情况下DDD批判的贫血对象看起来很不合理，另一些情况下在这些对象上添加一些方法又会带来不必要的频繁变动和相互干扰呢？原因在于：混淆了对象的固有内在行为和外界对这些对象的操作行为。

让我们通过一个对比例子来理解这种混淆。
有3个日历牌：第一个是简单的一组纸卡片台历，月份是印着1-12的12个纸牌，日期是31个纸牌；第二个是一个有一堆齿轮组的万年历，年、月、日是3个互相联动的轮子；第三个是一个电子日历牌，在年、月、日下面各有一组“+”和“-”按钮。
第一个台历，年月日随便set，只要范围没有超出，你会避免setMonth(2)然后setDay(31)，但一个3岁的小屁孩儿可能会这么做，并且能够成功。你不可能也不应该把你的逻辑强加给这本台历，更不可能将你的逻辑通过这个台历传递给孩子。这个对象本来就几乎什么逻辑都没有，如果你把自己脑子里一套关于关于日历的逻辑硬塞进去，就偏离了本质。
第二个台历，因为齿轮是互相咬合的，因此不能随便set，只能increaseDay(int step)和decreaseDay(int step)，并且当日期是2014年2月28日时，调用increaseDay(1)，日期会变成2014年3月1日。这是这台机械万年历的内在固有行为，无论谁来使用它，都只能按照它的规律来操作，否则就会弄坏它。这对这个机械台历，放心地把其内部的设定和规律放在对象内的方法里，不用担心它的使用者的逻辑经常变化、互相影响。
第三个台历，操作起来方便一些，年月日都直接可调，相比机械万年历多了increaseYear(int step)、decreaseYear(int step)、increaseMonth(int step)、decreaseMonth(int step)4个方法。但是，当这个电子台历做了一个固件升级之后，增加了新的功能：按住按钮2秒后，会快速持续增加或者减少对应的数字，直到你松开手！原来又弄错了，对于一个电子台历，按钮只是传递外部操作事件，具体做什么是由软件决定的，一个有bug的软件在你按下“+”的时候实际上让数字往下走也不是不可能。因此应该是：Calendar.dayIncreaseButtonDown(int durationInSecond)、Calendar.dayDecreaseButtonDown(int durationInSecond)、……、Calendar.Display(Date date)，至于按下按钮后有什么反应，在CalendarFirmware对象中实现吧。