DDD 聚合建模和领域服务

Question

我正在阅读有关 DDD 的内容，并试图了解它如何应用于各种情况。

那么，让我们以LoanApplication 为例。要提交这样的申请，用户需要填写各种Sections（例如PersonalDetailsSection、BusinessAssetsSection等）。

这些部分中的每一个都独立于其他部分，即如果有人完全更改 PersonalDetailsSection 而不是 BusinessAssetsSection，则不会违反不变量。

此外，这些部分中的每一个都非常复杂，有很多一对多的关系，所以对我来说，这些部分可能是不同聚合根的候选者。 LoanApplication 可以是另一个 AggregateRoot，仅包含单独部分的 ID（聚合根）。

在 UI 前端，用户在向导式屏幕中填写每个部分的详细信息（首先是个人详细信息，然后是业务资产等）。他或她可以随时保存LoanApplication 的临时版本，最后他或她可以保存最终版本。应用程序最终确定意味着应检查所有部分是否包含有效信息（例如，没有空白字段），并且不允许对应用程序和每个部分进行进一步更改。

我遇到的第一个问题是，如果我将每个部分作为单独的 AggregateRoot，那么每当用户完成 LoanApplication 时，就需要对所有 AggregateRoot（包括 LoanApplication）进行一系列检查和更改。这是我可以在此处使用的域服务示例，目的是确保所有部分都包含有效数据并最终确定每个部分？这样的服务应该是这样的

try {
  businessSection.finalise();
  personalSection.finalise();
  loanApplication.finalise();
  ...
} catch (InvalidDataException e) {
  //handle exception;
}

我遇到的第二个问题是关于更新聚合根。聚合根可以通过身份引用其他聚合根。因此，假设创建了一个新的 Section 并获得了一个新的 id。现在LoanApplication 聚合根需要引用新的 id。谁负责更新 LoanApplication 中的内容？

感谢您的任何回答！

Answer 1

此外，这些部分中的每一个都非常复杂，有很多一对多的关系，所以对我来说，这些部分可能是不同聚合根的候选者。

是的，它们没有任何重叠的一致性规则这一事实是一个好兆头。

我遇到的第一个问题是，如果我将每个部分作为单独的 AggregateRoot，那么每当用户完成 LoanApplication 时，就需要对所有 AggregateRoot（包括 LoanApplication）进行一系列检查和更改。

您可能想用一种稍微不同的方式来考虑这个问题：当您从已准备好的部分创建贷款应用程序的实例时，您可能希望将这些部分中的信息视为不可变的输入值贷款申请汇总。

因此，有效贷款申请的业务逻辑不同于有效草稿的业务逻辑。

因此，假设创建了一个新的 Section 并获得了一个新的 id。现在 LoanApplication 聚合根需要引用新的 id。谁负责更新 LoanApplication 中的内容？

贷款申请将成为其所在州的权威机构。应用程序之外的信息（例如有一个新部分）作为函数参数传递给贷款应用程序聚合。

听起来您想要的方法是：部分更改，因此应将信息发送到贷款申请。有很多不同的方式可以安排这一点 - 聚合可以相互发送消息，可以使用人作为中介，可以使用流程作为中介，等等。