event-sourcing – 在事件采购中处理CRUD“表”

我正在开始ES之旅并想知道传统支持表是否应存储在事件日志中,还是应该以不同方式处理?这些表通常具有CRUD页面.换句话说,在同一个应用程序中有两种方法是常见的,一种用于支持表,一种用于事务数据?

支持表类似于会计应用程序中的“帐户”或“产品类型”或ERP应用程序中的实际“产品”表(我不是在编写ERP应用程序 – 这是我所使用的表类型的示例谈论).

如果我们在事件日志中存储CRUD类型的数据,那么我们可能会有事件:

> ProductCreated
> ProductUpdated
> ProductDeleted(只会将其标记为已删除)

然后,我们是否尝试找出更改的内容(在ProductUpdated事件中)并只存储更改和重播以获取产品的最新图像?

大多数情况下,我正在使用什么方法来使用CRUD表 – 传统或存储在事件日志中?其他信息会很棒!

最佳答案 假设您完全使用事件日志,包括ProductCreated等事件,而不是其他数据存储.然后会发生的是,每次应用程序启动时,它都必须重放日志中的所有事件以构建其当前状态.

现在,假设您创建了一个传统的SQL表来存储应用程序的当前状态(比如产品表)以及为了达到该状态而处理的最后一个事件的ID(比如last_event表).然后,每当您的应用程序启动时,它必须仅重放ID高于存储ID的事件,并处理这些事件以构建其新状态.

另一方面,您的应用程序现在必须小心保持这两个状态同步.如果你需要并发,你需要小心只在你的SQL表上进行原子操作 – 但这对于事务来说应该相当容易.

点赞