domain-driven-design - 事件溯源 - 如何聚合

Question

我试图了解如何在事件溯源模型/DDD 中实现这一点。

假设一个分布式应用程序，用户在其中提交某项应用程序，例如 Job/Loan。所以应用程序引发了一个UserApplied事件。

很少有微服务像credit service，criminal record service.. 他们使用这个UserApplied事件做一些验证，响应CriminalCheckPassed，CreditCheckPassed......等等。假设有 5 次检查要做。将来我们可能还会添加更多这样的检查。

应用程序使用这些事件并做出一些决定。也就是说 - 只有当它们都被成功验证后，应用程序才能通过将状态更改为来批准用户应用程序UserApproved。任何验证都失败了，它们将是UserDeclined. 类似的东西。

听起来很简单。但是我在敲我的脑袋如何正确地实现它？

这是我的活动商店

我有一个物化视图

如果我们必须在收到事件时更新物化视图/聚合，应用程序需要 5 个不同的事件来做出决定。到那时才会pending。即使我收到了第 5 个事件，物化视图也不知道它之前收到了多少个事件。我将最终查询整个事件存储。

另一种方法是 - 在物化视图中添加这些列。这样我们就知道我们是否收到了所有这些事件。它会起作用的。但是长得超级难看。

我的问题是 - 在这种情况下如何正确使用聚合？

标签： domain-driven-designevent-sourcing

Answer 1

如果我理解正确，验证是域逻辑的一部分（必须确保它通过）。在这里，有一些外部服务，如信用服务和犯罪记录服务。

首先，我将User建模为实体和自身的聚合根。然后，我将Job Application建模为另一个实体和另一个自身的聚合根。现在有 2 个聚合，关系如下：User can have many Job Applications。

现在，您需要在创建Job Application实例之前验证一些事情。此验证需要来自其他服务的一些知识。这可以通过创建域服务来解决，例如JobApplicationCreationService，其唯一职责是创建Job Application的新实例。然后，您需要在此处注入这些外部服务。在服务内部，使用您注入的服务进行验证，然后如果所有验证都通过，则返回一个新的Job Application实例。此聚合实例将满足您的验证规则/域逻辑。

这里的事件不适合验证，而是用于使用最终一致性在聚合之间同步状态。当事件被发布并被处理时，您希望确保产生事件的聚合已经处于一致状态（在本例中为作业应用聚合）。

这是我个人的经验法则：尝试从静态工厂方法创建一个聚合以包含创建逻辑。如果创建需要聚合本身边界之外的东西，请将其重构为域服务。