如果会议从未发布过，则会议管理限界上下文允许业务客户删除座位类型，但不会引发集成事件向订单和注册限界上下文报告这一情况。所以，当业务客户创建新的座位类型时，订单和注册限界上下文从会议管理限界上下文接收事件，而不是当业务客户删除座位类型时。
迁移过程的一部分创建一组集成事件，以替换V1版本处理后丢弃的事件。它通过读取会议管理限界上下文使用的数据库来创建这些事件。此过程没有为已删除的座位类型创建集成事件。
总之，在V1版本中，已删除的座位类型错误地出现在订单和注册限界上下文的读模型中。在迁移到V2版本之后，这些已删除的座位类型没有出现在订单和注册限界上下文的读模型中。
.gif)
测试迁移过程不仅验证迁移是否按预期运行，而且可能揭示应用程序本身的bug。 总结
在我们旅程的这个阶段，我们对系统进行了版本控制，并完成了V2伪生产版本。这个新版本包含了一些额外的功能和特性，比如支持不需要付费的订单和在UI中显示更多信息。
我们还对基础设施做了一些改变。例如，我们使更多的消息具有幂等性，现在持久化集成事件。下一章将描述我们旅程的最后阶段，我们将继续增强基础设施，并在准备发布V3版本时加强系统。