我想对此清楚。当我说领域性贫血时，我的意思是故意性领域性贫血，不是偶然的。在我们的大多数业务逻辑都被一堆服务隐藏起来的世界中，真的需要一个完整的域模型吗？
自从从事“领域”模型实际上是持久性模型的项目以来，这是我最近不得不问自己的问题。没有一个域对象包含任何方法，这是一个非常有意的决定。
最初，当我看到一个充满了本质上是类型安全的数据容器的库时，我感到不安，但经过一番思考，我感到震惊的是，这个特定的系统除了基本的CRUD操作之外，并没有做很多事情，因此在这种情况下，这是一个不错的选择。我想我的问题是，到目前为止，我的经验主要集中在富域模型上，因此使我感到有些惊讶。
域逻辑的其余部分隐藏在一组单独的程序集中的助手，外观和工厂中。
我很想听听人们对此的想法。显然，重用这些类的考虑要简单得多，但确实有很大的好处吗？
最佳答案
我同意可能不需要完整的域模型。但是，我确实认为为具有模拟数据访问对象的服务编写测试要比为非贫乏域对象编写测试要痛苦得多。我现在正在一个项目中，除了领域模型之外，领域逻辑无处不在，分散在帮助者，策略和中介中，整个事情甚至在投入生产之前就已成为一堆难以管理的遗留代码。
回想一下以前的项目，我确实记得一个使用贫血的领域对象的项目，它存在很多问题，包括一个糟糕的本地xml数据库，但是由于它确实采用了基于服务的方法，因此很容易一次就解决一个问题。时间并取得真正的进展。在当前项目中，他们试图变得更加聪明，并且将域对象与ActiveRecord风格的数据库相关联，并且没有做出任何努力来控制它们的依赖关系。域对象与数据库的紧密耦合，静态方法的过度使用以及类似意大利面条的依存关系，已成为导致此代码库过早变脆，不灵活且不可测试的泥潭的重要原因。因此，我认为尽管忽略持久性的富域对象使业务逻辑的测试变得容易得多，但最重要的是管理依赖项。
关于design-patterns - 面向服务的体系结构是否适合域性贫血？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/2767103/