Eig*_*ite 14 soa design-patterns anti-patterns
我想明确这一点.当我说域贫血时,我指的是故意的域贫血,而不是偶然的.在我们大多数业务逻辑隐藏在一堆服务背后的世界中,完整的域模型真的是必要的吗？
这是我自从最近开始研究一个项目的问题,其中"领域"模型实际上是一个持久性模型; 没有域对象包含任何方法,这是一个非常有意的决定.
最初,当我看到一个充满了本质上类型安全的数据容器的库时,我打了个哆嗦,但经过一番思考后,我觉得这个特定的系统没有做太多但基本的CRUD操作,所以也许在这种情况下这是一个不错的选择.我想我的问题是,到目前为止我的经验一直非常关注丰富的域名模型,所以它让我有点兴奋.
域逻辑的其余部分隐藏在一组生成在单独组件中的帮助器,外墙和工厂中.
我很想知道人们对此的看法.显然,重用这些类的考虑因素要简单得多,但实际上是非常有益吗？
我同意可能没有必要使用完整的域模型.但是,我认为使用模拟数据访问对象编写服务测试比编写非贫血域对象测试更痛苦.我正在开发一个项目,现在域名逻辑存在于除了域模型之外的任何地方,分散在帮助者和策略和调解器中,并且整个事情在它开始生产之前就变成了无法管理的遗留代码.
回想以前的项目,我确实记得一个使用贫血域对象的问题,它有很多问题,包括一个糟糕的本土xml数据库,但是因为它确实采用了基于服务的方法,因此很容易解决问题.时间并取得实际进展.在当前项目中,他们试图变得聪明并将域对象绑定到数据库,ActiveRecord样式,并且没有做任何努力来控制它们的依赖项.域对象与数据库的紧密耦合,过度使用静态方法以及类似意大利面条的依赖关系网已经成为导致这个代码库成为过早脆弱,不灵活和不可测试的泥球的重要组成部分.所以我认为,虽然持久性无知的丰富域对象使业务逻辑的测试变得更加容易,但重要的是管理依赖项.
我认为,一个贫穷的领域,而OO反模式实际上是一种SOA模式.随着我们提升抽象级别,规则发生了一些变化.
我正在编写一系列文章进一步探索,去年我的日志上也有一个关于它的咆哮.metallemon.blogspot.com/2008/07/soa-and-anemic-domains.html
http://hubpages.com/hub/Building-Service-Orientated-Architecture
六年后，这需要重大更新。
简单的答案是肯定的。但复杂的答案是否定的。
不，SOA 不需要贫血。但同时，不需要使用 SOA 编写企业系统。同样，架构对于任何代码都不是必需的。这将是一场噩梦，但如果您愿意，您可以将每一点功能都打包到一个模块中。
简单地说：OO 最初的定义是它与其前辈的不同之处。更具体地说：C++ 是通过它与 C 的不同来定义的。但是 OO 的定义已经改变了。我们现在有很多 OO 原则。
免责声明：这些原则中的许多部分或全部是在面向对象之前创建的，并且在面向对象革命期间被简单地声明或更新。另外，我意识到 OO 已经出现在 LONG-Before C++ 中，但这并没有改变我的说法：
封装、继承、多态、关注点分离、持久性无知、高内聚/低耦合、S、O、L、I、D 等等。
不仅如此，如果您在遵循这些原则的同时遵循 DDD 和/或 TDD，您几乎根本不需要架构。只要遵循这些原则，您自然会得到一个使用贫血领域模型的面向服务的架构。
想想看。如果您有一个 Employee 类，其中包含Save()、SendMessage()和PayEmployee()... 您违反了当前 OO 原则的许多规则。
当您分析某些职责并将其提取到不同的服务、存储库、命令、工厂等中时……您不禁有一个空的员工类……有点。
老实说，您需要牢记值对象的想法。不仅 OO 的定义发生了变化，“贫血”的定义也发生了变化。Employee 类当然不应该为空。它可以包含大量的“业务逻辑”。
Employee 类可以有：
本质上，Employee 仍然是贫血的。会有一定永远不会在领域模型中的任何算法或代码流的逻辑。但不只有一种业务逻辑。
当 Martin Fowler 在十多年前说贫血领域模型是一种反模式时，它已经变得越来越可行。他的推理是双重的，而这两种观点都是旧闻。
他的第一个折叠首先是他对 OO 的辩护定义是代码和数据结合在一起，或“将数据和过程结合在一起”，与旧的程序风格相反。不幸的是，这仅适用于糟糕的代码。如果我们遵循继承和多态，我们就会知道函数并不真正存在于类中。它们位于指针处，以便继承类可以覆盖和移动它们。但是……它们是否存在于代码中以提高可读性？他们当然不应该！它们应该在接口和抽象中定义，并且只在类中实现。抱歉，Martin，虽然你说的对，代码/数据联姻是 OO 2 几十年前的一个巨大的原始卖点，但现在已经不是那么重要了。
他的第二个观点是他认为 SOA 的做法不正确，并指出了一些与我们今天所说的 N 层架构非常相似的描述。当然，我意识到这不是新技术，但多年来定义已经发生了变化。
不仅是 Martin Fowler，他之后的许多其他人也立即引用了他的文章，因此说 SOA 本身就是一种反模式，因为它需要贫血模型，Fowler 说这是一种反模式。
贫血领域模型并不像人们认为的那样贫血。而 SOA 是必需的，我们不能打折扣。不幸的是，事情就是这样。
为什么需要 SOA？- 这太描述了。但长话短说：在 90 年代，域软件运行在 PC 和服务器上……而硬件“插入”了这些单体。如今，我们身边几乎拥有数万亿台“计算机”。烟雾探测器、冰箱、手表、电话……如今，计算机已融入事物之中。所以每一个想法、部门、CONCERN和对象都是它自己的小领域。我们要求 SOA 将它们写成自己的小服务，甚至是子服务。
因此：应用程序现在插入服务（而不是服务插入应用程序）。要创建 SOA，我们只需遵循 OO 的当前规则，例如 SOLID 和关注点分离。当我们这样做时，我们自然会到达贫血领域模型......有点。
所以不，SOA 不需要贫血领域模型。它们是遵循当前原则和标准的自然结果。