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

12-07-15 flyzb

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

[该贴被flyzb于2012-07-15 17:09修改过]

gameboyLV

2012-07-15 18:07

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

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

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

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

banq

2012-07-15 20:47

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

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

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

相关帖：

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

RRiBbit：开源事件总线EventBus框架

状态对象：数据库的替代者

[该贴被banq于2012-07-18 15:28修改过]