【问题标题】:Maintain reference between aggregates维护聚合之间的引用
【发布时间】:2020-05-09 14:50:31
【问题描述】:

我正在努力思考如何维护两个聚合之间的 id 引用,例如。当任何一方发生影响关系的事件时,另一方也会以最终一致的方式进行更新。

在节日的上下文中,我有两个聚合,一个用于“团队”,一个用于“活动”,代码如下:

@Aggregate
public class Event {
    @AggregateIdentifier
    private EventId eventId;
    private Set<TeamId> teams; // List of associated teams

... protected constructor, getters/setters and command handlers ...
}
@Aggregate
public class Team {
    @AggregateIdentifier
    private TeamId teamId;
    private EventId eventId; // Owning event

... protected constructor, getters/setters and command handlers ...
}

团队必须始终与事件相关联(通过 eventId)。一个事件包含相关团队的列表(通过团队 ID 集)。 在 Team 聚合上创建团队 (CreateTeamCommand) 时,我希望使用新创建的团队的团队 ID 更新 Event 聚合上设置的 TeamId。 如果执行事件聚合上的命令“DeleteEventCommand”,则与该事件关联的所有团队也应被删除。 如果团队从一个事件转移到团队聚合上的另一个事件 (MoveTeamToEventCommand),则应更新团队聚合上的 eventId,但应从旧 Event 聚合中删除 TeamId,并将其添加到新 Event 聚合中。

我目前的想法是创建一个传奇,我将在 Event 聚合上的 eventId 和 Team 聚合上的 teamId 运行 SagaLifecycle.associateWith,并在“CreateTeamCommand”上使用 @StartSaga(基本上是关系第一次开始) 然后为影响关系的每个事件都有一个事件处理程序。我对这个解决方案的主要问题是:

1:这意味着对于团队和赛事的每种可能组合,我都会有一个独特的传奇。如果将其缩放到例如,这是否会导致性能问题。 100 万场赛事,每场赛事有 50 支球队? (这对于这种情况是不现实的,但与维护聚合之间关系的一般解决方案相关)。

2:这将需要我有自定义命令和事件处理程序专门用于处理事件聚合的团队列表中的团队更新,因为不应在 saga 中处理结果事件以避免更新引用的无限循环。

感谢您阅读这个小故事,我希望有人可以确认我在正确的轨道上,或者为我指明正确解决方案的方向。

【问题讨论】:

    标签: cqrs event-sourcing axon


    【解决方案1】:

    一个事件包含相关团队的列表(通过团队 ID 集)。

    如果您在此处通过“事件”来表示“事件聚合”,我认为您的事件聚合不需要团队 ID。如果您认为确实如此,那么了解您对此的推理会很棒。

    我认为您需要的是通过您的阅读方了解这一点。您对单个“事件”的读取模型可以监听 CreateTeamCommandMoveTeamToEventCommand 以及所有其他“事件”相关事件,并相应地构建投影。记住,don't design your aggregates with querying concerns in mind

    如果事件聚合上的命令“DeleteEventCommand”被执行,与该事件关联的所有团队也应该被删除。

    这里有几件事:

    • 同样,您的读取端可以监听此事件,并相应地更新预测。
    • 您还可以开始对Team 聚合的相关命令处理程序进行验证,以在执行操作之前检查Event 是否存在。这不会精确同步,但会涵盖大多数情况(请参阅“我如何在下订单时验证客户 ID 确实存在?”部分 here)。
    • 如果您真的想从DeleteEventCommand 事件的后面删除关联的Team 聚合,您需要在Saga 中进行处理,因为您无法在原子方式,不会将数据存储系统细节泄漏到您的域模型中。因此,您需要一定的重试和幂等性需求,而 saga 可以为您提供。这并不是您在这里所建议的,但相关的事实是单个命令不能作用于一组聚合,请参阅“如何使用单个命令更新一组聚合?”部分here

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2010-11-30
      • 2014-08-30
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多