重新认识“对象”和“行为”之间的关系

  DDD中强调“领域对象是拥有行为的”。这句话我觉得说法是正确的,但是其做法难道就是“在领域对象里写方法”这么简单吗?
  我们常说“类应该具有生命的”,但我不认为“把方法写到类里就会让类具有生命了”,因为"把简单地把方法写到类里,其最终也只是让类变成了一潭死水,是经不起风浪的,是无法变成湖泊和海洋的”。类不会无缘无故产生行为,类能够产生行为一定是在一定的场景下发生的。在我看来,“简单地把方法写进类里是无法描述多(复杂)场景下的类的行为的”。如果有人说在他的项目里那样做没问题,那我只能说他的项目(场景)还不够复杂。
  其实“贫血对象”和“充血对象”都是极端的做法,而问题的关键是“类如何合理而自然地拥有行为”。在我看来,我们只能在“贫血对象”和“充血对象”之间达成一种平衡。如何把“场景”更好地融入DDD还有没公论,但我想“类合理而自然地拥有行为”应该是一条准则。
[该贴被flyzb于2012-07-15 17:09修改过]

换一个思路就很好理解了,领域对象是有状态的业务对象。

我们之前的大部分工作都在持久层,所以就理所当然的将领域对象划分为贫血还是充血。

假设我们的项目只有表示层,服务层,领域层,那么领域层需要做什么呢?实现领域内的业务逻辑,并记住每次业务的处理状态。

这样也就不存在贫血还是充血的问题了,将领域状态持久化是持久层的工作。

综合两位想法,实体对象的行为是用来维持实体状态的一致性或完整性的,也就是原来由数据库完成的数据完整性。见这个案例讨论

实体对象中只要有这些基本方法即可,其他行为可以由对象运行时的多义性来实现,比如mixin或场景dci或事件等。

当然,这些都是行为的实现方式,行为到底应该是划入实体边界,还是由场景或事件或服务实现,必须从职责这个角度考虑,从职责这个角度考虑,可以更加认清行为的本质,对其边界的划拨有重要指导意义。


相关帖:
新的对象定义
我们以后也许不能再用类概念代指对象了,类可以生成对象,函数也可以生成对象。

RRiBbit:开源事件总线EventBus框架

状态对象:数据库的替代者
[该贴被banq于2012-07-18 15:28修改过]