解决贫血域模型示例答案

【问题标题】：Resolving Anemic Domain Model example解决贫血域模型示例
【发布时间】：2012-09-17 01:17:17
【问题描述】：

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

class MortgageCalculator {
  Mortgage mortgage; // mortgage object containing loanAmount, interest rate, etc.;
  calculateMonthlyPayment(); // calculates monthly payments using mortgage object's properties
}

class Mortgage { // Anemic?
  loanAmount;
  interestRate;
}

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

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

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

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

【问题讨论】：

标签： domain-driven-design anemic-domain-model

【解决方案1】：

也许Mortgage 对象可以执行部分计算。例如，考虑一个计算订单总额的对象：

for (Line line : orderLines)
  int total += line.getPrice() * line.getQuantity();

这是一个已知的Feature Envy，可能是：

for (Line line : orderLines)
  int total += line.calculateTotal();

【讨论】：

【解决方案2】：

MortgageCalculator 实际上并不是域实体，因为它没有填充到数据库中，因此为了避免贫血，您可以将逻辑合并到Mortgage 实体中：

class Mortgage {
   loanAmount;
   interestRate;

   calculateMonthlyPayment();
}

另外一点：DTO 与领域实体不同，DTO 是用于在分布式环境中传输数据，而领域实体是专注于领域逻辑。

您可以将域实体用作 DTO，因为在某些情况下，DTO 与域实体具有相同的属性。但是，大多数情况下，取决于每个客户端，也许他们需要获取需要多个域实体的数据。因此，为了关注点分离和更易于维护，建议创建与域实体分离的 DTO：

class MortgageDto {
   loanAmount;
   interestRate;
}

【讨论】：

【解决方案3】：

如果您不了解有界上下文 (BC)，就无法进行 DDD。那么在这种情况下，BC 是什么？因为一切都取决于此。

根据我对你的理解，我认为你有一个 MortageCalculator 很好，因为你可以有多种计算抵押贷款的方法。这个类可以有一个方法，该方法将采用 Mortgage 参数。当然，我所说的可能是错误的，因为我不知道您的域。

如果碰巧不是所需领域的专家，就很难回答有关 DDD 的具体问题。但一切都从 BC 开始，那么您的 BC 是什么，抵押贷款的业务角色是什么？

【讨论】：