丰富的域模型与贫血域模型

哪个是Web开发,贫血域模型或富域模型的更好实践？

贫血域模型意味着实体是映射到某些持久存储的愚蠢POJO.getter和setter不验证状态转换,但信任上面的层.服务层负责验证实体的合法状态,并在违反业务规则时发出错误.这就是我习惯使用Spring和Hibernate构建Web应用程序的方法.

富域模型意味着验证逻辑(业务规则)驻留在实体本身中,例如,如果尝试非法状态转换,则从setter抛出异常.

在给出更深入的洞察之后,富域模型更接近于OOP原则,其中贫血域模型与将结构传递给C函数一样程序化(实际上,setter和getter在这里只是一个样板,以纪念javabean契约) .那么为什么更多采用贫血领域模型,这两种方法的优缺点是什么？

我可以看到富域模型的一些问题.例如,如果实体的有效状态取决于某些其他实体的状态,但实体没有对所有实体的引用,那么我们如何从实体内部验证状态？我们可以从setter访问数据库,但这会将持久性机制泄露给业务逻辑,这确实是一个非常糟糕的设计.此外,当ORM从数据库加载已经验证的对象并设置其值时,将执行不必要的验证!借助驻留在服务层中的业务逻辑,随着需求的变化,更容易添加临时验证逻辑,并使域模型保持清洁基础架构代码.实际上在任何一种情况下都是业务逻辑IS与持久性相关联,并且在实践中,域模型在没有逻辑的情况下毫无价值,但是当逻辑驻留在服务中时,我们可以将不同的规则集应用于不同上下文中的相同实体.我认为这是服务层的目的吗？

此外,hibernate或其他持久性机制期望实体是POJO,并且只对获取和设置值感兴趣.当然,富域模型数据库应始终处于一致状态,但如果不是,会发生什么？富域模型对现代ORM框架有何影响？

当我最近读到贫血领域模型是反模式时,我问了这个问题.我感到困惑,并希望听到这样一个声明的理由.