将关系数据迁移到事件存储
我正在使用我自己的 CQRS 模式实现将旧项目迁移到 CQRS。我开始这次迁移的主要原因是为了摆脱 n 层架构造成的混乱。然而，与许多其他项目一样，该项目正在使用关系数据存储。
此过程中的当前状态是我有进行更改的命令和隔离查询的查询对象。这意味着从客户端到服务器，我有一种类似 CQRS 的方式来更改和查询数据，尽管我没有发布更改中的任何事件，也没有非规范化的读取存储。我应该提到的是，我也有相当贫乏的 DTO 作为我的“域模型”。所有行为都分布在 n 层及其处理程序、管理器和所有那些可怕的层事物中。
我想知道我该如何采取下一步。我现在想要的是开始构建一个负责其行为的域模型，原因是我想开始使用事件存储作为事实来源，这让我想到了我的问题：
如何我将数据从关系数据存储迁移到事件存储中？
我有一个极其规范化的数据模型，其中包含非常重要的数据，必须进行迁移。我确实明白，我不能期望从该数据中捕获任何意图，因为它已经死了，但我应该用它做什么？我应该创建大量迁移命令吗？很高兴听到您的经验。
I am migrating an old project towards CQRS using my own implementation of the CQRS pattern. The main reason I started this migration was to get rid of the mess the n-tier architecture had caused. The project however, as many others, is using a relational data store.
The current state in this process is that I have Commands that make changes and Query objects that isolate the querying. This means that from the client to server, I have a CQRS-ish way of changing and querying data although I do not publish any events from the changes, nor do I have a denormalized read store. I should mention that I also have pretty anaemic DTOs as my "domain model". All behaviour was distributed throughout the n-tier layers with its handlers, managers and all those horrible layer things.
I want to know how I can take the next step. What I want now is to start building a domain model that is in charge of its behaviour and the reason for that is that I want to start using an event store as the source of truth which brings me to my question:
How can I migrate the data from the relation data store into the event store?
I have an extremely normalized data model with very important data, which has to be migrated. I do understand that I cannot expect to capture any intent from that data as it is dead, but what should I do with it? Should I create loads of migration commands? It would be nice to hear your experience from this.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我还没有机会尝试这个，但我想尝试的东西可以在多个阶段中发挥作用：
我认为事件写入事件存储的顺序有点棘手，需要一些思考。但鉴于这是一个迁移过程，只要域的最终状态正确，我认为这并不重要。如果您的关系表有时间戳，那么这可能会有所帮助。
我认为构建事件对象比创建命令更合适，因为关系数据代表过去发生的操作的域。
I’ve not had the opportunity to try this but something I wanted to try would work in a number of stages:
I would imagine that the sequence in which the events are written to the event store is a bit tricky and would require a bit of thought. But seeing as this is a migration process then as long as the final state of the domain is correct I don’t think it matters to much. If your relational tables have timestamps then this could help.
I decided that building event objects was more appropriate rather that creating commands because the relational data represents the domain for actions that have happened in the past.
我的处理方式与所提供的解决方案不同。我已经在两个不同的项目中完成了两次迁移。
让命令执行写入操作并使用查询执行读取操作的第一步是良好的第一步。
我要做的下一件事是从执行写入的相同命令引发事件。适应活动的举办。
这仅仅意味着在命令处理程序中只需构建事件并将它们推送到 EventStore 中。
在项目生命周期中越早开始提交事件，应用程序中的历史记录就越多。
现在，继续在命令处理程序中执行对规范化数据库的写入。
一旦您有几个引发事件的命令处理程序，下一步就非常容易了。构建一个事件处理程序/反规范化器，侦听引发的事件并简单地执行与命令处理程序完全相同的写入操作。
您现在所做的就是将 WRITE 职责移至非规范化器并远离命令处理程序。
这基本上就是我推荐的过程，正如我所说，我已经这样做了两次并且有效。
将数据库中的现有数据迁移到事件的问题有点棘手。您必须将该数据视为当前状态，因此您可以做的就是构建并提交（使用您编写的某些实用程序）为系统中的所有数据创建事件。
例如，要迁移现有的 Accounts 表，您需要编写一个 AccountCreatedEvent 并将其与表中每个帐户中的所有数据一起提交。
Id approach this differently to the solutions offered. Ive done this migration twice on 2 different projects.
Your first step of having commands do the writes and queries do the reads is a good first step.
The next thing I would do is raise events from the same commands that do the writes. Get comfortable with the event raising.
This simply means in the command handler just build the events and push them into the EventStore.
The earlier in the projects life you start committing events, the more history you have in your app.
Now, continue to perform the writes to the normalized database in your command handlers.
Once you have a couple of command handlers raising events, the next step is quite easy. Build an event handler/denormalizer that listens for the raised event and simply performs EXACTLY the same write operation the command handler did.
All you have done now is move the WRITE responsibility into the denormalizer and away from the command handler.
Thats basically the process I would recommend, as I said, Ive done this twice and it works.
The matter of migrating EXISTING data in your data base to events is a little tricky. You have to think of that data as the current state, so all you can do I build and commit (using a some utility you write) Create events for all the data in your systems.
Eg, to migrate an existing Accounts table, you'd write an AccountCreatedEvent and commit it with all the data in each account in the table.