域模型模式示例

域模型模式示例

我理解正确吗？如果没有，我将举一个例子。

大致上是。

对于Martin Fowler而言，
领域模型是领域的对象模型，其中包含行为和数据 。
域模型经常与模型相对，在模型中，您有特定的类来承载数据，而其他一些特定的类来承载行为/处理。

如果我参加您的

Income

课程，它看起来更像是一个拥有属性/数据的类，而不是具有真实行为的域模型。

public boolean isPositive(){   return amount > 0 ? true : false;}

是一种与模型无关的效用函数。
您可以将其放在

Math

课堂上。

我将尝试为您提供一个域模型示例，然后再提供该模型将数据和处理分开的版本。

假设您要建模的应用程序领域的需求中，我们需要为收入增加奖金。例如，此奖金可能发生在圣诞节的冬季（但为什么不参加其他活动）

让域模型对象执行任务，而不是让服务类进行此处理。

Incomes

，高级对象可以在

Income

实例上进行迭代并应用奖励，我们可以有一个奖励规则类，该规则类根据一些输入值定义奖励。
我介绍了多个类，因为这种想法是允许每个对象根据其职责进行协作。

收入：

public class Incomes {  List<Income> incomes = ...  ....  public void applyBonus(BonusRule bonusRule){     for (Income income : incomes){       income.applyBonus(bonusRule);     }      }

收入：

public class Income {  private float amount;...  public void applyBonus(BonusRule bonusRule){       float bonus = bonusRule.compute(this);       amount += bonus;  }      ...}

ChristmasRule：

public class ChristmasBonusRule implements BonusRule {...  @Override  public float compute(Income income){       float bonus = ...       return bonus;    }      ...}

最后，我们可以通过以下方式进行处理：

void foo(){     // create a domain object that has both behavior and data  Incomes incomes = ...;   // invoke a functional method on the object by passing another domain object  incomes.applyBonus(new ChristmasBonusRule()); }

在将数据和逻辑划分为不同类的设计中，它看起来像这样：

public class IncomeBonusService {  // stateless : no incomes data inside it  ....  public void applyChristmasBonus(List<Income> incomes){     for (Income income : incomes){       // Christmas bonus computation here       float bonus = ...       income.setAmount(bonus + income.getAmount());     }  }}

我们可以这样处理：

// inject the service@AutowiredIncomeBonusService incomeBonusService;void foo(){          // create a domain object that has only data   List<Income> incomes = ...;    // invoke a service method by passing data as parameter   incomeBonusService.applyChristmasBonus(incomes); }

对象没有任何行为（只有getter / setter）的模型设计称为Anemic Domain
Model。

---

此示例说明的两种方式之间的巨大差异：

领域模型：

• 对象是有意义的。

• 在班级之间明确定义了行为责任。
  因此具有良好的隔离性，可测试性和可维护性。
  例如，添加/删除/单元测试a

  BonusRule

  很容易。

• 对象负责其状态。
  的确，由于对象本身可以在与其他对象协作之后更新其状态，因此无需提供设置器。
  我们可以在中看到

  Amount.applyBonus()

  ：

float bonus = bonusRule.compute(this); amount += bonus;

贫血领域模型：

• 所有逻辑都在服务类中。
  因此，一个地方即可获取代码。
  只需几行，就可以了。
  但是请注意，这种优势有一定的局限性，因为随着逻辑变得庞大或复杂，最好的事情通常是将逻辑拆分为多个服务类。

• 但是，无论您需要多少服务类，整个逻辑都位于服务类中，而不是其他位置。如果我们将其与可能在某些不同的“类型”类中分解逻辑的领域模型进行比较，则可以简化开发规范。

• 为域类提供获取/设置程序的必要性。
  该域也不负责其状态及其不变规则。
  因此，任何依赖域类的类都可以“破坏”其状态。

附带说明一下，默认情况下，某些框架（用于持久性，映射，序列化等）依赖于getter / setter。
这就是为什么这种模型尽管有缺点，但却在某些项目中处于领先地位的原因。