该死的贫血模型

http://martinfowler.com/bliki/AnemicDomainModel.html 。 我也写过了多年的贫血模型的代码，但这两年来，我越来越意识到它的危害性！ 贫血模型让我们把业务逻辑和实体数据分离，把大量的逻辑写在所谓的Service类里面，结果就导致实体成了C语言的结构体，而service就成了一个个C函数，又回到了过程化地编写C程序的时代。Martin Fowler把这种service叫做transaction script，就是事务脚本，换句话说，实体变成了数据库的一个变体，service变成了针对于这个变体进行编程的脚本，本质上就是一段事务脚本，没有领域概念体现的地方。面向数据库编程在应对复杂多变的领域问题时的不足，早已经被人们认识到，所以人们才会发明出用领域驱动设计这种方法。然而贫血模型让我们在领域驱动设计前面来了一个180度大转弯，越走越远。 领域驱动设计借助面向对象来实现领域，可以说领域驱动设计正是面向对象应用于富业务逻辑软件开发上的一种更具体的解决方案。贫血模型，不仅不是领域驱动设计，还鼓励人们背离面向对象，回到过程化的编程方式。戴上贫血模型的有色眼镜，所有的东西，不是结构体一样的实体，就是直接访问数据的DAO，剩下的都是Service，而service则成以一个过程的集合。本来强大的面向对象的能力，在这样的编程模式中被遗忘了。把数据和行为分离，就直接不符合封装的原则。把所有逻辑都放到几个service类中，而让其它的类都没有逻辑，这也不符合职责单一的原则。贫血模型并不符合面向对象的思想。 为什么我们会写出贫血模型这样的代码呢？我想，这和spring+hibernate等误导有关系。在hibernate和Java EE中，被冠以entity名称的数据库表映射类，实际上并不一定是领域模型驱动里的实体的概念。但是我们却被误导了，以为映射类就是实体类。然而，映射类是由hibernate动态创建的，想在其中通过spring注入其它业务对象，实现一些复杂的功能，不容易实现。为了避免麻烦，于是大家习惯于让映射类里只包含和数据库对应的数据，而不包含业务逻辑。进尔把所有的业务逻辑都搬到一个个Service里实现，逐渐形成了贫血模型的编程习惯。 要想领域驱动开发，首先就不要误入所谓贫血模型的邪道！

转载于:https://my.oschina.net/komodo/blog/919165