domain-driven-design - 轴突框架 : send command on aggregate load

Question

我们正在使用 Axon Framework 4.1 构建微服务系统。在我们的领域中，我们有一个标签概念，我们可以将标签附加到其他实体。虽然标签通常由用户创建和管理，但其中一些标签是“特殊的”，需要进行硬编码，但它们也需要出现在事件流中。

我们有一堆表示可以用这些标签标记的实体的聚合。其中一些聚合会经常使用，而其他聚合可能很少使用，甚至被用户放弃。

有时我们会想出新的特殊标签。我们将它们添加到代码中，然后我们还需要将它们添加到事件流中。这样做的好方法是什么？

我们可以创建一个特殊的命令，当更新的服务第一次启动时，我们需要发送这个命令。它遍历所有标签并添加尚未出现在事件流中的标签。这有两个缺点。首先，我们需要实际发送该命令，这要么要求我们不要忘记它，要么在代码之外(例如，在我们的构建管道中)为其添加一些基础设施。此外，其他服务可以使用新标签更快地启动，并在我们发出特殊命令之前开始发送命令。另一个缺点是此命令将针对所有聚合，包括废弃的聚合，这可能会浪费资源，并使最终用户感到困惑，他们可能会在他们认为已废弃的文档中看到事件。

理想情况下，我们希望能够在 Axon 刚刚加载聚合时发送命令。这样我们就可以确定标签只在实际使用的聚合中引入。此外，我们可以在代码中连接它，它不需要我们在应用程序之外添加基础设施和/或记住手动完成。

不幸的是，这个功能在 Axon 中似乎不存在(目前)😉。

是否有其他(更好的)方法来实现这一目标？

Answer 1

我有一个想法可以帮助你解决这个问题。

如果我正确理解了用例，那么您系统中的“标签”(用户可以自我介绍但也存在几个硬编码版本)是一个聚合。
基于这个假设，我建议对您正在使用的聚合标识符保持聪明。

Axon 对您的唯一期望是，聚合标识符是(或可以制成)String .通常是 UUID用于聚合标识符，这是一个合理的开始。
但是，您可以包装此 UUID在类型标识对象中。以您的“标签”聚合体为例，它会选择 LabelId .

也就是说，让我们首先回到验证事件流中是否存在给定的“标签”聚合。
我认为你的担忧是有道理的；读取整个 Event Stream 以确定给定的 Aggregate 实例是否存在非常麻烦。

然而，EventStore可以通过两种机制查询:

来自给定时间点的事件流(例如 TrackingToken 机制的作用)。

给定聚合实例的事件流，基于聚合标识符。

这是第二种选择，在您的场景中更为理想。
只需查询 EventStore对于给定的“标签”聚合的标识符。如果您收到一个非空的 Event Stream，您就知道它已经存在。
反之亦然，如果未找到 Events，则您确定这是一个需要引入的新“标签”。

这里的关键在于预先知道“标签的”聚合标识符，它可以追溯到 String使用类型化 LabelId 的聚合标识符的存储方法.你能做的是偏离 LabelId自定义“标签”(我在这里选择 UUID)和硬编码的“标签”之间的对象。
例如，对于后者，您可以使用 label-name ，加上一个 UUID/counter 如果需要。

这样做将确保从硬编码“标签”发布的所有事件都将具有您可以在启动期间预期的聚合标识符。

希望这很清楚，如果没有，请在下面评论我的回复。