2

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

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 对象主要用于对象之间的数据传输等。

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

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

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

4

3 回答 3

3

Perhaps the Mortgage object can perform parts of the calculation. For example, consider an object that calculates an order total:

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

This is a known as Feature Envy, and could be:

for (Line line : orderLines)
  int total += line.calculateTotal();
于 2012-09-17T02:41:57.923 回答
2

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

class Mortgage {
   loanAmount;
   interestRate;

   calculateMonthlyPayment();
}

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

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

class MortgageDto {
   loanAmount;
   interestRate;
}
于 2012-09-17T04:49:40.917 回答
0

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

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

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

于 2012-09-18T07:09:14.257 回答