哪种更好的网络开发实践，贫血领域模型或丰富的领域模型？
贫血领域模型意味着实体是映射到某些持久存储的愚蠢POJO。 getter和setter不验证状态转换，但信任上面的层。服务层负责验证实体的合法状态，并在违反业务规则时发出错误。这就是我习惯使用Spring和Hibernate构建Web应用程序的方法。
富域模型意味着验证逻辑（业务规则）驻留在实体本身中，例如，如果尝试非法状态转换，则会从setter抛出异常。
在深入了解之后，富域模型更接近于OOP原则，其中贫血域模型与将结构传递给C函数一样程序化（事实上，setter和getter只是一个样板，为了纪念javabean合同）。那么为什么更多采用贫血领域模型，这两种方法的优缺点是什么？
我可以看到富域模型的一些问题。例如，如果实体的有效状态取决于某些其他实体的状态，但实体没有对所有实体的引用，那么我们如何从实体内部验证状态？我们可以从setter访问数据库，但这会将持久性机制泄露给业务逻辑，这确实是一个非常糟糕的设计。此外，当ORM从数据库加载已经验证的对象并设置其值时，将执行不必要的验证！借助驻留在服务层中的业务逻辑，随着需求的变化，更容易添加临时验证逻辑，并使域模型保持清洁基础架构代码。实际上在任何一种情况下业务逻辑都与持久性相关联，并且在实践中，域模型在没有逻辑的情况下毫无价值，但是当逻辑驻留在服务中时，我们可以将不同的规则集应用于相同的实体。不同的背景。我认为这是服务层的目的吗？
此外，hibernate或其他持久性机制期望实体是POJO，并且只对获取和设置值感兴趣。当然，富域模型数据库应始终处于一致状态，但如果不是，会发生什么？富域模型对现代ORM框架会产生什么影响？
我问过这个问题，因为我最近读到贫血领域模型是一种反模式。我感到困惑，并希望听到这样一个声明的合理性。