我们有需要重写的具有复杂业务逻辑的旧遗留应用程序。我们考虑使用 cqrs 和事件溯源。但目前尚不清楚如何从旧数据库迁移数据。可能我们只需要将它迁移到读取数据库，因为我们无法重现所有事件来填充事件存储。但是我们至少需要在事件存储中为每个聚合创建一些初始记录，比如AggregateCreated?或者我们需要编写一个脚本并以我们通常使用事件溯源的方式一一使用所有命令来重新创建聚合？
【问题讨论】：
标签： domain-driven-design cqrs event-sourcing
使用现有数据库或其转换版本作为读取端持久性的开始绝不是一个好主意。您的事件溯源系统需要启动，因此您可以获得事件溯源的主要好处之一 - 能够使用多语言持久性按需创建预测。
使用命令进行迁移也不是一个好主意，原因很简单，根据定义，命令可能由于不变控制的前置或后置条件检查而失败。它也没有传达迁移的含义，即表示当前系统状态。请记住，当前的系统停留不是您可以接受或拒绝的。它是给你的，你的工作就是捕捉它。
此类迁移的最佳做法是发出所谓的迁移事件，例如EntityXMigratedFromLegacy。当然，这项工作可能很重要。主要是因为遗留系统模型很可能与新模型不匹配，否则这种迁移的原因并不完全清楚。
通过使用迁移事件，您可以明确声明一个状态是从另一个地方原样移动的。您将始终知道迁移的实体是如何在新系统中开始其生命周期的 - 无论是从旧系统迁移还是在新系统中初始化。
【讨论】：
可能我们只需要将其迁移到读取数据库
不，您的读取模型数据库可以根据写入端随时删除和重新创建，只有写入端才是您的真实来源。
但我们至少需要在事件存储中创建一些初始记录 每个聚合，比如 AggregateCreated？
当然，只有初始事件是不够的。如果您当前的 OrderAggregate 有预订，则必须为其拥有的每个预订创建 ItemReservedEvent。
或者我们需要编写一个脚本并一一使用所有命令 以我们通常使用事件溯源的相同方式重新创建聚合？
感觉这就是你应该走的路。从 db 读取旧的聚合/实体并尝试将其映射到新的聚合/实体。
【讨论】：