architecture - 现有关系数据库上的 Cqrs 和事件溯源

Question

我们有一个用 C++ 和一个关系数据库编写的现有应用程序。该应用程序需要用 c# 重写，业务需要某种跟踪什么时间由谁更改的内容。 CQS 似乎很适合读/写，但事件源似乎几乎不可能，因为现有应用程序仍需要与新应用程序一起使用。现有的 c++ 应用程序使用直接写入数据库的组件(数据 View )。要发展，我们将不得不更改 C++ 应用程序中所有那些可编辑的表，以使用命令为我们的新应用程序调用服务，这是非常昂贵的。

我们需要一种架构，在这种架构中我们可以在不破坏旧的 c++ 应用程序的情况下从旧的发展到新的，并且它们需要协同工作。

我们有一个想法，就是为事件溯源准备好一切，但不使用它。然后创建两个应用程序写入的一些跟踪表。 block 准备就绪后，我们会在新应用程序中激活该部分，并在旧的 C++ 应用程序中停用它。

但实际上，在传输过程中什么时候存储在现有数据库中是最佳时机？在 CommandHandler 中？在事件处理程序中？事件 UserAdded 在逻辑上可能仅在真正添加用户时才发送。我们认为制作临时命令处理程序将是最佳选择。

或者有什么其他想法？

Answer 1

我认为将触发器添加到 SQL 数据库并为每次创建/更新/删除生成事件会很好。然后只需使用这些事件在新的 CQRS 系统中构建读取模型。

接下来你应该考虑你想要什么数据库，因为你可以使用旧的或新的数据库。如果使用旧数据库，您应该在 sagas 中为新的 CQRS 应用更新它。这两个应用程序都会从​​旧数据库中读取。如果使用新数据库，您将拥有一个读取模型或一些新数据库，如 Mongo(甚至是 SQL - 这取决于数据的大小和结构)。这两个应用程序都将从新数据库中读取。是的，您应该更改旧 C++ 应用程序中的一些代码。

An idea we have is just preparing everything for event sourcing but not using it. Then creating some tracking tables where both apps writes to. Once a block is ready, we activate that part in the new app and deactivate it in the old c++ app.

因为计划迁移到 CQRS 我建议你使用第二种方式。