我正在使用我自己的 CQRS 模式实现将一个旧项目迁移到 CQRS。我开始此迁移的主要原因是摆脱 n 层架构造成的混乱。然而，与许多其他项目一样，该项目正在使用关系数据存储。
此过程中的当前状态是我有进行更改的命令和隔离查询的查询对象。这意味着从客户端到服务器，我有一种 CQRS 式的更改和查询数据的方式，尽管我没有发布来自更改的任何事件，也没有非规范化的读取存储。我应该提一下，我的“领域模型”也有相当贫乏的 DTO。所有行为都分布在 n 层及其处理程序、管理器和所有那些可怕的层中。
我想知道我该如何迈出下一步。我现在想要的是开始构建一个负责其行为的域模型，其原因是我想开始使用事件存储作为事实来源，这让我想到了我的问题：
如何将数据从关系数据存储迁移到事件存储？
我有一个非常规范化的数据模型，其中包含非常重要的数据，必须迁移。我明白我不能指望从该数据中捕获任何意图，因为它已经死了，但我该怎么处理它呢？我应该创建大量迁移命令吗？很高兴听到您的经验。
我没有机会尝试这个，但我想尝试的东西可以分几个阶段工作：
我想将事件写入事件存储的顺序有点棘手，需要一些思考。但鉴于这是一个迁移过程，只要域的最终状态是正确的，我认为这并不重要。如果您的关系表有时间戳，那么这可能会有所帮助。
我认为构建事件对象比创建命令更合适，因为关系数据代表了过去发生的动作的域。
Id 以不同的方式处理所提供的解决方案。我已经在 2 个不同的项目上完成了两次迁移。
让命令执行写入和查询执行读取的第一步是很好的第一步。
我要做的下一件事是从执行写入的相同命令中引发事件。对活动发起感到满意。
这仅仅意味着在命令处理程序中只需构建事件并将它们推送到 EventStore。
您在项目生命周期中越早开始提交事件，您在应用中的历史记录就越多。
现在，继续在命令处理程序中执行对规范化数据库的写入。
一旦你有几个命令处理程序引发事件，下一步就很容易了。构建一个事件处理程序/反规范化器，它侦听引发的事件并简单地执行与命令处理程序完全相同的写入操作。
您现在所做的就是将 WRITE 职责移到非规范化器中并远离命令处理程序。
这基本上就是我推荐的过程，正如我所说，我已经完成了两次并且它有效。
将数据库中的现有数据迁移到事件的问题有点棘手。您必须将该数据视为当前状态，因此您所能做的就是构建和提交（使用您编写的某个实用程序）为系统中的所有数据创建事件。
例如，要迁移现有的 Accounts 表，您将编写一个 AccountCreatedEvent 并将其与表中每个帐户中的所有数据一起提交。
第一步，我将根据领域驱动设计原则创建丰富的领域模型来绘制聚合边界。然后进一步过渡到事件溯源将非常简单。这里有一些关于这个主题的帖子