我正在阅读DDD，我正试着看看它将如何在各种情况下应用。
那么，让我们以LoanApplication为例。要提交此类申请，用户需要填写各种Sections（例如PersonalDetailsSection，BusinessAssetsSection等等。
这些部分中的每一部分都独立于其他部分，即如果某人完全更改PersonalDetailsSection而不是BusinessAssetsSection，则不会违反任何不变量。
此外，每个部分本身都很复杂，有很多一对多的关系，所以对我来说这些部分可能是不同聚合根的候选者。 LoanApplication可能是另一个仅包含单独部分ID（聚合根）的AggregateRoot。
在UI前端，用户在向导样式屏幕中填写每个部分的详细信息（首先是个人详细信息，然后是业务资产等）。在任何时候，他或她都可以保存LoanApplication的临时版本，最后他或她可以保存最终版本。应用程序最终化意味着应检查所有部分是否包含有效信息（例如，没有空字段），并且不允许对应用程序和每个部分进行进一步更改。
我遇到的第一个问题是，如果我将每个部分作为单独的AggregateRoot，那么每当用户最终确定LoanApplication时，都需要对所有AggregateRoots进行一系列检查和更改（包括{{1 }}）。这是我在这里可以使用的域服务示例，目的是确保所有部分都包含有效数据并最终确定每个部分吗？这样的服务看起来像这样
LoanApplication我遇到的第二个问题是更新聚合根。聚合根可以通过标识引用其他聚合根。所以，让我们说创建一个新的try {
businessSection.finalise();
personalSection.finalise();
loanApplication.finalise();
...
} catch (InvalidDataException e) {
//handle exception;
}
并获得一个新的id。现在Section聚合根需要引用新的id。谁负责更新LoanApplication中的内容？
感谢您的回答！
答案 0 :(得分：0)
此外，每个部分本身都很复杂，有很多一对多的关系，所以对我来说这些部分可能是不同聚合根的候选者。
是的，他们没有任何重叠的一致性规则这一事实是一个好兆头。
我遇到的第一个问题是，如果我将每个部分作为单独的AggregateRoot，那么每当用户完成LoanApplication时，都需要对所有AggregateRoots（包括LoanApplication）进行一系列检查和更改。
您可能想要以一种稍微不同的方式来考虑：当您从已准备好的部分创建贷款申请实例时，您可能希望将这些部分中的信息视为不可变的输入值。贷款申请总量。
因此，有效贷款申请意味着什么的商业逻辑与有效的草案意味着不同。
所以，让我们说一个新的部分被创建并获得一个新的id。现在LoanApplication聚合根需要引用新的id。谁负责在LoanApplication中更新？
贷款申请将成为其所在州的权力机构。应用程序之外的信息（如有新部分的事实）将作为函数参数传递给贷款申请汇总。
听起来您想要的方法是：部分更改，因此该信息应发送到贷款申请。有许多不同的方法可以安排这个 - 聚合可以发送彼此的消息，您可以使用人作为中介，您可以使用进程作为中介，等等。