【问题标题】:CQRS (event sourcing): Projections with multiple aggregatesCQRS(事件溯源):具有多个聚合的预测
【发布时间】:2019-05-10 07:55:37
【问题描述】:

我有一个关于 CQRS 架构上涉及多个聚合的预测的问题。

例如,假设我有两个聚合 WorkItem 和 Developer 并且以下事件顺序发生(但不是立即发生)

  1. WorkItemCreated (workItemId)
  2. WorkItemTitleChanged(workItemId,标题)
  3. DeveloperCreated (developerId)
  4. DeveloperNameChanged (developerId, name)
  5. WorkItemAssigned (workitemId, DeveloperId)

我希望创建一个作为 developer-workitem 的“内部连接”的投影:

| WorkItemId | DeveloperId | Title  | DeveloperName | ... |
|------------|-------------|--------|---------------|-----|
| 1          | 1           | FixBug | John Doe      | ... |

我进行预测的方式是渐进式的。这意味着我从数据库中加载保存的预测并应用剩余的事件。

我的问题是,负责在投影表上创建一行的事件是WorkItemAssigned。但是,该事件不包含以前事件的所需信息(工作项标题、开发人员名称等)

为了在WorkItemAssigned 之前获得所需的信息,我必须从事件存储中加载所有 事件,并将所有@987654327 的状态 保存在内存中@ 和 Developers 所以在 WorkItemAssigned 事件到达时我已经获得了所需的信息。

当然,我可以有一个Workitem 的投影,另一个Developer 的投影,并查询它们以检索它们的最后状态。但是看起来工作量很大,如果我要为每个聚合分别创建投影,我还不如创建一个数据库视图来inner-join它们(实际上,这就是我正在做的.)

我不是手动完成所有这些,我目前正在使用一个名为 EventFlow 的好框架,但它并没有指示我回答这个问题。

这是一个关于 CQRS 基础知识的问题,我觉得我在这里遗漏了一些东西。

【问题讨论】:

    标签: cqrs event-sourcing


    【解决方案1】:

    我认为你没有遗漏任何东西。在事件源系统中投影读取模型与从关系模型中查询不同,会带来一组不同的问题。这些问题并非必然更容易或更难解决;它们只是不同。

    好消息是您有很多选择。事件溯源允许您以任何可以想象的方式投影数据,因此您可以决定最适合每个单独投影的解决方案。我猜“坏”消息(我认为这不是坏消息)是每次问题的解决方案都与使用 JOIN 构造查询的关系系统不同。

    您已经确定了一些可能的解决方案:

    • 使用关系模型作为您的读取模型之一
    • 当某种类型的事件到来时,重新查询包含您需要的数据的流,并使用它们进行按需投影

    您也可以简单地将一些数据保存在临时状态(在内存、文档数据库、文件系统等),这样您就可以在需要时查找数据并进行投影。因此,请保留更新的 WorkItems 和 Developers 的列表,以便在 WorkItemAssigned 事件出现时可以读取和使用它们。

    我会说创建一个关系数据库作为临时或永久读取模型是解决问题的一种完全可行的方法,假设您不尝试实现大规模可扩展性。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2018-12-28
      • 2018-04-28
      • 2011-03-07
      • 2020-03-20
      • 1970-01-01
      • 1970-01-01
      • 2019-01-31
      • 1970-01-01
      相关资源
      最近更新 更多