代码之家 › 专栏 › 技术社区 › Fabio Marreco

cqrs(事件源):具有多个聚合的预测

event-sourcing cqrs

2

Fabio Marreco · 技术社区 · 6 年前

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

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

工作项已创建(工作项ID)
WorkitemTitleChanged(工作项ID,标题)
developer已创建(developerID)
developerMechanged(developerID,名称)
工作项已分配(工作项ID,developerID)

我希望创建一个作为开发人员工作项“内部连接”的投影:

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

我做预测的方式是渐进式的。也就是说,我从数据库中加载保存的投影,并在它们出现时应用其余的事件。

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

以便在规定时间内获得所需信息 工作项已分配 ,我必须加载 全部的 事件存储中的事件,保留状态所有人的记忆 WorkItems 和 Developers 所以我在 工作项已分配 事件到达。

当然,我可以有一个投影 Workitem ,另一个用于 开发商 并查询它们以检索它们的最后状态。但这似乎需要做很多工作,如果我要分别为每个聚合创建投影,我不妨创建一个数据库视图来 内连接 他们(事实上,我就是这么做的。)

我不是手工完成的,我目前正在使用一个很好的框架 EventFlow ,但这并不能指导我回答这个问题。

这是一个关于cqrs基本原理的问题,我觉得我在这里遗漏了一些东西。

1 回复 | 直到 6 年前

1

Phil Sandler 6 年前

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

好消息是你有很多选择。事件源允许你以任何可想象的方式投射数据,所以你可以决定一个最适合于每个投影的解决方案。我猜“坏”消息(我认为这不是坏消息)是,问题的解决方案与关系系统(即使用连接构造查询)的解决方案每次都不一样。

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

使用关系模型作为读取模型之一
当某种类型的事件出现时,重新查询包含所需数据的流,并使用它们按需投影

您还可以简单地将一些数据保存在临时状态(内存、文档数据库、文件系统等)中,以便在需要时查找并投影数据。因此,保留更新的工作项和开发人员的列表,以便在工作分配事件发生时可以读取和使用它们。

我想说,创建一个关系数据库作为一个临时的或永久的读取模型是解决这个问题的一个完全可行的方法,假设您没有试图实现巨大的可伸缩性。