design-patterns - 领域贫血在面向服务的架构中是否合适？

Question

我想澄清这一点。当我说领域性贫血时，我的意思是 故意的领域性贫血，并非偶然。在一个我们的大部分业务逻辑都隐藏在一堆服务之后的世界里，一个完整的领域模型真的有必要吗？

这是我最近在从事一个“领域”模型实际上是持久性模型的项目后不得不问自己的问题。没有一个域对象包含任何方法，这是一个非常有意的决定。

最初，当我看到一个库中充满了本质上是类型安全的数据容器时，我感到不寒而栗，但在一些人认为这个特定系统只做基本的 CRUD 操作时，我感到震惊，所以在这种情况下，这可能是一个不错的选择.我想我的问题是，到目前为止，我的经验一直非常关注丰富的域模型，所以它让我有点吃惊。

域逻辑的其余部分隐藏在一组助手、外观和工厂中，它们位于一个单独的程序集中。

我很想听听人们对此的看法。显然，重用这些类的考虑要简单得多，但真的有那么大的好处吗？

Answer 1

我同意可能不需要完整的域模型。但是，我确实认为使用模拟数据访问对象为服务编写测试比为非贫血域对象编写测试更痛苦。我现在正在做一个项目，除了域模型之外，域逻辑无处不在，分散在助手、策略和中介中，甚至在投入生产之前，整个事情就已经变成了一堆难以管理的遗留代码。

回想以前的项目，我确实记得一个使用贫血的领域对象的项目，它有很多问题，包括一个糟糕的本土 xml 数据库，但是因为它确实采用了基于服务的方法，所以很容易一次性解决这些问题时间并取得真正的进展。在当前项目中，他们试图巧妙地将领域对象与数据库联系起来，采用 ActiveRecord 风格，并且没有做出任何努力来控制它们的依赖关系。领域对象与数据库的紧密耦合、静态方法的过度使用以及意大利面条式的依赖关系网络是导致该代码库过早变得脆弱、不灵活和无法测试的泥球的重要原因。所以我认为虽然不了解持久性的富域对象使业务逻辑的测试变得更加容易，但最重要的是管理你的依赖关系。