域分析是否适合于面向服务的体系结构？

Question

我想澄清这件事。当我说范围贫血时，我指的是故意的结构域贫血，而不是偶然的。在一个我们的大部分业务逻辑都隐藏在一堆服务后面的世界中，一个完整的域模型真的有必要吗？

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

一开始，当我看到一个包含了本质上是类型安全的数据容器的库时，我不寒而栗，但当我想到这个特定的系统只做了基本的CRUD操作之后，我觉得这是一个很好的选择。我的问题是，到目前为止，我的经验非常集中在一个丰富的领域模型，所以它让我有点。

域逻辑的其余部分隐藏在一组驻留在单独程序集中的助手、外观和工厂中。

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

Answer 1

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

回想以前的项目，我确实记得有一个项目使用了贫血的域对象，它有很多问题，包括一个糟糕的本地xml数据库，但是由于它确实采用了一种基于服务的方法，所以很容易一次解决一个问题，并取得真正的进展。在当前的项目中，他们试图变得聪明，并将域对象绑定到数据库，ActiveRecord风格，并且没有做出任何努力来控制它们的依赖关系。域对象与数据库的紧密耦合、对静态方法的过度使用以及类似意大利面的依赖网络是导致这个代码库过早变得脆弱、不灵活和不可测试的一个重要部分。所以我认为，尽管持久化无知的富域对象使业务逻辑的测试变得更加容易，但最重要的是管理您的依赖关系。

Answer 2

我认为贫血域，而OO反模式实际上是SOA模式。规则已经发生了一些变化，因为我们已经提高了抽象级别。

在我写的系列文章中，我正在作进一步的探索，去年我的日志上也有过关于这件事的咆哮。https://metallemon.blogspot.com/2008/07/soa-and-anemic-domains.html

http://hubpages.com/hub/Building-Service-Orientated-Architecture

Answer 3

六年后，这需要一次重大的更新。

简单的回答是肯定的。但复杂的答案是否定的。

不SOA不需要贫血。但同时，不需要使用SOA编写企业系统。类似地，任何代码都不需要体系结构。这将是一场噩梦，但如果您愿意，可以将每个功能打包到一个模块中。

简单地说: OO最初是根据它与其前身的不同来定义的。更具体地说: C++是根据它与C.的不同来定义的，但是OO的定义已经改变了。我们现在有许多面向对象的原则。

免责声明:这些原则中有许多是在OO之前部分或全部创建的，只是在OO革命期间被简单地声明或更新。而且，我意识到OO早在C++之前就已经存在了，但这并没有改变我的声明：

封装、继承、多态性、关注点分离、持久性无知、高内聚力/低耦合、S、O、L、I、D等。

不仅如此，如果您在遵循这些原则的同时遵循DDD和/或TDD，那么您几乎不需要进行架构设计。通过遵循这些原则，您自然会得到一个面向服务的体系结构，它使用贫血的领域模型。

想想看。如果您有一个带有Save()、SendMessage()和PayEmployee()的雇员类.你违反了很多现行OO原则的规则。

当您将某些职责分析并提取到不同的服务、存储库、命令、工厂等中时.你不能帮但是有一个空的雇员类..。说大也大吧。

说大也大吧?

诚实地说，你需要记住价值对象的概念。不仅OO的定义已经发生了变化，“贫血”的定义也发生了变化。当然，Employee类不应该是空的。它可以包含大量的“商业逻辑”。

Employee类可以有：

• 参数化构造函数，其中对参数进行验证。
• 计算字段的只读属性
• Employee.ToString()、Employee.TryParse()和类似的对象方法
• 可能是员工特有的其他人

从本质上说，雇员仍然是贫血的。肯定不会在域模型中使用任何算法或代码流逻辑。但这不仅仅是一种商业逻辑。

当马丁·福勒( Martin )在十多年前说贫血领域模型是一种反模式时，它已经变得越来越可行。他的推理是双重的，这两种说法都是老生常谈。

他的第一条折页是，他对OO的辩护定义是，代码和数据是结合在一起的，或者“将数据和处理结合在一起”，而不是旧的程序风格。不幸的是，这只适用于糟糕的代码。如果我们遵循继承性和多态性，我们就知道函数并不真正存在于类中。它们存在于指针中，这样继承类就可以覆盖和移动它们。但是..。它们存在于代码中以增加可读性吗？他们当然不应该！它们应该在接口和抽象中定义，并且只在类中实现。抱歉，马丁，虽然你的是对的，但代码/数据婚姻在20年前是OO的一个巨大的原始卖点，但现在已经不是那么简单了。

他的第二个缺点是，他取消了SOA被错误执行的资格，并指出了一些与我们今天所说的N层体系结构非常相似的描述。诚然，我意识到这并不是新技术，但多年来定义已经发生了变化。

不仅马丁·福勒( Martin Fowler )，而且他之后的许多人都立即引用了他的文章，因此说SOA本身就是一种反模式，因为它需要贫血的模型，福勒说这是一种反模式。

所以我们决定..。

贫血领域模型并不像人们所相信的那样贫血。SOA是必需的，我们不能低估它。不幸的是，事情就是这样的。

为什么需要SOA？--这太描述性了。但是长话短说:在90年代，软件运行在PC和服务器上.和硬件“插入”这些单石。这些天来，我们周围都有“电脑”的万亿美元的“电脑”。烟雾探测器，冰箱，手表，电话…这些天来，的电脑插入了的东西。因此，每个想法、部门、关注的和对象都是它自己的小域。我们需要SOA将它们写入自己的小服务，甚至子服务。

因此:应用程序现在插入服务(而不是插入应用程序的服务)。要创建SOA，我们只需遵循OO的当前规则，例如实体和关注点分离。当我们这样做的时候，我们自然会得出贫血的域模型..。大概吧。

所以不，SOA不需要贫血的领域模型。它们是遵循现行原则和标准的自然结果。