在事件建模中，以事件的形式保存业务数据。事件是已经发生的事实，我们在每次操作后都会将其存储起来。事件流记录了我们的记录所发生的一切。很遗憾，你不能更改事件，因为它们是不可变的。但你可以在最后添加一个新的事件，弥补过去的错误。
下面6种方法介绍如何从传统的数据表CRUD范式中找到领域事件，从而迁移到事件溯源架构中。
1. 查找状态栏
找出他们拥有什么数值；通常，它们可能反映数据的生命周期阶段。
例如，对于订单，这个数值可以是已启动、已发货、已付款等。
这样这些数值可以迁移到订单发起、订单发货、订单付款等事件中。
- 当然，要小心谨慎，不要认为它们是完整的。它们可能是对业务流程的扁平化解释。一定要向更了解业务的人请教。
- 事件命名不是以CRUD增删改查命名： "创建订单"、"更新订单"、"删除订单"。
2.检查日期
日期列可以告诉你很多关于流程生命周期中重要事件的信息。如果这些事件足够重要，可以将其保留为专用列，那就说明了问题。
当然，"创建日期 "和 "修改日期 "不会告诉你太多信息，而"发货日期"、"交货日期 "和 "订单放置日期 "会给你提供更好的信息。它们既能告诉你业务术语，也能证实我们从状态中得到的假设，或者引入新的事件。
例如
- ShipmentDate 将是引入订单已发货事件的下一个线索、
- OrderPlacementDate 可以提示我们，"订单启动 "事件可能更适合命名为 "订单放置"，如果它们实际上是同一件事，最好与业务部门进行讨论、
- DeliveryDate 可能意味着我们还应该引入一个新的订单已交付事件。
同样，请与领域专家交流；他们可以帮助您了解业务流程的真相。
3.分析列的可选性
如果列是不可空的，则表示必须始终提供。可空表示它们可以稍后提供（因此在其他操作中），或者它们是可选的。
因此，在商品订购流程中，如果需要列，那么我们保存的数据也应在第一个 "订购启动 "事件中提供。请记住，单一事件类型并不总是数据流的起点，可能还有更多。
4.搜索具有最多 "1 对多 "关系的表格
在 Event Sourcing中，我们认为设置界限（边界感）是一个重要方面。为了使我们的处理有效，我们围绕业务流程对数据进行分组，而不是存储规范化。
- 要找到数据流边界，可以从查找具有 "1 到许多 "关系的表开始。那些有大量 "1 "关系的表就是数据流类型的候选表。
- 我们还应该从逻辑上思考这些数据是否可以互不影响。例如，装运可以是一个独立于订单的流程，但订单行不能没有装运。
一旦我们开始讨论这些界限，我们可能会发现更多的事件，并丰富我们对流程的理解。
5.不要撒谎，为导入引入明确的事件
一旦你分辨出所有你可以接受的事件并想要迁移关系数据，不要试图欺骗；不要在导入过程中重复使用你新发现的事件。关系型数据是扁平化的；如果您试图从最终状态中改造所发生的事情，您很可能会失败，或者最多是不精确。
最好的办法是明确地向 "订单导入 "事件提供所有当前状态和解释它的代码。这样我们就能清楚地了解我们是如何获得有关其生命周期的数据的，这对故障排除和诊断至关重要。
6.实验和验证
不要害怕做原型，看看你的模型是如何运行的。
在安全的环境中尝试迁移，将结果与预期进行比较，然后冲洗并重复。不要急于求成。我们不希望失去旧信息，但要在此基础上改善我们的未来。
希望本指南能帮助您恢复数据中的信息。