问题标签 [anemic-domain-model]

如果域实体不是贫血的，所以它们在自身中嵌入了特定的使用行为，是否需要/点来使用/构建特定的域服务？验证应该进入实体内部怎么样？

哪种方式对单元测试更灵活？

谢谢！

目前正在对从另一个团队接管的东西进行一些代码审查，并且对应用 SRP 及其与贫乏或丰富的域模型（由 Martin Fowler 定义）的关系存在疑问。富域模型概念是拥有智能对象，不仅可以设置/获取其属性，还可以执行一些更复杂的业务逻辑。我想知道它如何适合 SRP？

假设我的模型类具有一些属性，这些属性可以公开这些道具并对其属性提供一些简单的计算。下一个要求是有可能将此对象数据存储在一些不受我控制的存储对象中，如下所示：

存储中的存储方法

如果 MyObject 有这样的存储方法，它不会违反 SRP

从这个对象的 pov 来看，能够存储它的状态是一个很好的想法。其他方法可能是在这里引入某种服务并这样做：

您能指出我可以阅读有关此问题的任何链接吗？我在这里找到了一个关于 SO 的线程，但它并没有完全回答我的问题。

在 DDD 中是如何解决的？DDD 中的模型根据定义是丰富的，并且可以被视为具有太多的职责。

假设我已经定义了一组项目。这些项目必须分组到不同的集合中。例如项目可以像

集合有自己的设置，比如哪些项目属于这个集合，集合的名称是什么等等。现在所有的东西都存储在，比如 xml 结构中。

我的第一个想法是编写以下元素：

• xml 解析器获取集合的数据并转换为 MySet pojo

• xml 解析器获取所有项目并转换为项目 pojos 列表

• 无状态类服务类说 ItemsSetCreator 计算最终 ItemsSet 对象，其中包含基于 MySet 的集合定义和项目列表，例如

  /li>

但另一种方法是稍微丰富模型并编写如下内容：

• MySet 类能够获取所有项目，基于 xml-data 对它们应用内部逻辑并提供最终的 ItemsSet 作为结果

• 等等

我不知道哪个更好。我知道例如 Spring 提倡更多以服务为中心的方法，但最近有很多关于避免贫血模型的讨论。

情况：我正在为我的“持久层”使用 LinqToSql（可能被认为是无关紧要的），并试图解决我对某些可疑的业务相关逻辑应该去哪里的一些架构问题。

场景：应用程序的用户创建一个新订单。当他们这样做时，需要将一组产品密钥与该订单相关联。

我的第一次尝试是将所有这些爵士乐放在 OrderService 类中。然后，我尝试使用部分方法将它与我的 DataContext 合并：

忽略这不能按预期工作的事实（产品密钥实际上从未与订单相关联），我觉得这是从我的业务领域剥离逻辑并将其推送到我的“持久层”。我也想过把它放在一个 OrderService 类中，但觉得它也只是从域实体中拿走了逻辑并导致了一个事务脚本。引入订单工厂只是规避了这个问题：数据和逻辑再次分离。

所以我的问题是：为了避免贫乏的领域模型，并希望除了成为一个美化的数据结构之外还有秩序做一些事情，是否有一种将这种逻辑集成到我的领域模型中的适当方法？

我想出的最佳解决方案是将逻辑放入 Order 类并验证它是否已在验证挂钩中完成：

使用代码如下所示：

== 2012 年 3 月 29 日更新 ==

在使用 LinqToSQL（和 Web 窗体）时，我采用了命令/查询模式，不再将 LinqToSql DataContext 创建的实体用作到我的数据存储的映射。我所有的规则以及没有进入命令对象的内容，在某种程度上使它们成为应用程序的真正核心。

我试图了解 ADM 和 RDM 之间的区别。

我看到它的方式是 adM 和 RDM 讨论都归结为您实际确定工作流程的位置（对象协作）。RDM 将数据存储库对象和验证对象注入到业务对象（模型）的构造函数中。然后，业务对象方法定义使这些对象协作的工作流。

ADM 将所有这些协作对象（模型、存储库、验证对象）传递到 viewModel/controller 等。viewmodel/controller 的方法定义对象之间的工作流协作。

这是正确的还是我错过了更基本的东西？

我阅读了几篇文章，告知 Java EE 环境中的实体 bean 被认为是贫血的（意味着只包含 getter 和 setter 而没有实现行为）。

是什么阻止我将行为放入实体 bean 中？因此，会话 bean（无状态或有状态）可以将所有业务逻辑委托给它们（对于由实体拥有的逻辑有意义）。

我不明白为什么实体 bean 一定是贫血的。

刚才我输入这个问题时，出现了一个有趣的线程。我不认为它回答了我的问题。

我一直在使用 .NET MVC3 进行大量工作，希望有一个贫血模型。视图模型和编辑模型最好作为愚蠢的数据容器，您可以将它们从控制器传递到视图。任何类型的应用程序流都应该来自控制器，视图处理 UI 问题。在 MVC 中，我们不希望模型中有任何行为。

但是，我们也不希望控制器中有任何业务逻辑。对于较大的应用程序，最好将域代码与模型、视图和控制器（以及通常的 HTTP）分开并独立于模型、视图和控制器。因此，有一个单独的项目首先提供域模型（具有实体和值对象，根据 DDD 组合成聚合）。

我已经做了一些尝试，从一个贫乏的模型转向更丰富的域代码模型，我正在考虑放弃。在我看来，拥有既包含数据又包含行为的实体类违反了 SRP。

以网络上一个非常常见的场景为例，撰写电子邮件。给定一些事件，域有责任在给定 EmailTemplate、EmailAddress 和自定义值的情况下编写一个 EmailMessage 对象。模板作为具有属性的实体存在，并且自定义值作为用户输入提供。为了论证，我们还假设 EmailMessage 的 FROM 地址可以由外部服务 (IConfigurationManager.DefaultFromMailAddress) 提供。鉴于这些要求，富域模型似乎可以让 EmailTemplate 负责编写 EmailMessage：

这是我对富域模型的尝试之一。但是，在添加此方法后，EmailTemplate 负责包含实体数据属性和撰写消息。它大约有 15 行长，似乎分散了全班学生对成为 EmailTemplate 的真正含义的注意力——IMO 只是存储数据（主题格式、正文格式、附件和可选的发件人/回复地址）。

我最终将此方法重构为一个专门的类，该类的唯一责任是根据前面的参数编写一个 EmailMessage，我对此更满意。事实上，我开始更喜欢贫血领域，因为它帮助我保持职责分离，使类和单元测试更短、更简洁、更专注。似乎使实体和其他数据对象“没有行为”可以很好地分离责任。还是我在这里偏离轨道？

例如，考虑 Jobeet 教程中的首页：

类 CategoriesRepository 扩展 EntityRepository {

}

所以在控制器内部，我不必使用服务层来使用两个存储库。

有人可以给我任何建议吗？

根据我从Martin Fowler的理解，贫血意味着将业务逻辑与领域对象分离，这些对象被简化为琐碎的 getter 和 setter，而领域行为则被移至服务层。我错过了什么吗？

如果某个对象域没有任何行为，我们如何调用它？您能否提供一些非常简短的贫血域模型代码？

我正在审查可以优化我的抵押贷款计算工具设计的领域，主要用于学习目的。在阅读了贫血领域模型之后，我对创建丰富模型产生了兴趣，并注意到我当前的实现可能有贫血！这是伪代码中的当前实现：

目前 Mortgage 对象主要用于对象之间的数据传输等。

以下是我正在考虑的一些修订选项：

1. 将 Mortgage 对象从 MortgageCalculator 中移除，并将 Mortgage 纯粹用作 DTO，而计算器的方法带有参数（例如，calculateMonthlyPayment(loanAmount,interestRate)。这将有助于将 MortgageCalculator 与 Mortgage 对象分离，但仍会将 Mortgage 作为贫血模型.
2. 将这两个类合并为一个“丰富的” MortgageCalculator 模型，该模型包含业务逻辑（例如，calculateMonthlyPayment）和抵押属性（例如，loanAmount）。我在这里担心的是我不确定计算器对象是否有必要将其操作数作为实例变量保存，但它们会促进数据传输、存储并可能解决贫血问题？

我想知道理想的方法是什么，或者我是否错过了重点？