java - 如何使用事件源(axon 框架)处理传奇中从 REST-API 传递的多个实体？

Question

目前我正在使用事件源和 CQRS 来实现带有 axon 框架的传奇。

具体情况如下:

我有 3 个微服务，m1、m2 和 m3

用户在 GUI 中输入 3 个实体 e1、e2、e3 的数据，分别由 m1、m2、m3 处理和保存，因此 m1->e1、m2->e2、m3->e3

现在谈谈这个传奇的必要性:

没有 e2 就不能存在 e1，没有 e3 就不能存在 e2。

因此，所有 3 个实体都必须由各自的服务成功创建，如果其中一个实体失败，saga 需要执行补偿事务以确保一致性。首先，m1 创建 e1，发出 e1CreatedEvent，然后协调器发送 createE2Command 作为对此的 react ，等等。

现在我的问题:

如何获取/存储用户输入的信息？在单个 RequestBody 中？那么我该如何处理这些数据呢？因为它需要以某种方式缓存才能与命令一起发送。

例如，m1 创建一个 createE1Command 并将 e1 中的信息添加到其中，然后在成功创建后，编排器将启动一个 createE2Command，然后将 e2 的信息添加到该命令中，然后再将其发送....如果发生这种情况，e2 的信息需要以某种方式存储起来，直到需要为止。

示例代码:

@Saga
public class ManagementSaga{

@Autowired
private transient CommandGateway commandGateway

@StartSaga
@SagaEventhandler
public void handle (e1CreatedEvent e1CreatedEvent){


  commandGateway.send (new CreateE2Command (e1CreatedEvent.Id, **HERE NEEDS TO BE THE INFO THAT THE USER CREATED PREVIOUSLY**)}}

我是否只创建一个对象来保存这三个实体的信息？那种感觉真的不对。

现在我明白，选择这样的领域模型可能真的很糟糕，如果可能的话应该避免它，但这是为了科学:-)

Answer 1

在这种情况下，我的第一 react 是对设计提出质疑。似乎(微)服务是围绕实体设计的。这种类型的设计可能在某些场景中有效，但在其他场景中将不可避免地导致分布式整体。您面临的挑战暗示了后者。

从 API 角度来看，交互与系统设计方式似乎也存在不匹配。虽然按照定义来说并不是错误的，但这也可能表明 API 不正确(没有正确反射(reflect)系统的行为)，或者行为模型不正确。

无论如何，为了给你一个比“这取决于”更有用的答案，你可以在多个命令甚至查询中得到一个交互结果。并非在所有情况下都需要 Saga。

接受包含有关 E1、E2 和 E3 信息的单个请求。然后在 Controller 中发送命令来创建 E3，根据该命令的结果创建 E2，最后创建 E1。不需要“缓存”任何信息。请求信息在整个过程中都是可用的。然而，这种方法不是事务性的。如果服务崩溃，进程可能会执行一半。

另一种方法是使用一个命令处理程序来注册用户的原始意图。这并不是要创造 E1、E2 或 E3，而是包含这三者的东西。进程生成的事件会触发 Saga 单独执行每个步骤，并使用这些步骤中的事件触发下一步。此过程是具有最终一致性特征的事务性过程。

我希望这是有道理的。但是，我会认真重新考虑服务的模型/设计，让它们更多地关注流程(步骤)而不是实体(状态)。我见过太多微服务项目因以实体为中心的设计而失败......