迁移指南
迁移有两条主路径：首次采用 Wow 解决的是领域边界、数据建模和流量切换； Wow v6 → v8 解决的是精确源 tag 对应的平台差异、源码兼容和存储格式切换。已经使用 Wow v8 且自定义运行时生命周期的系统，还需执行其中的运行时编排专项迁移；它不是第三种 业务或数据迁移。请先选择主路径，不要把两套步骤混在同一次发布中。
选择迁移路径
| 当前状态 | 目标 | 应阅读 | 不应混入 |
|---|---|---|---|
| 传统 CRUD / 事务脚本 / 直接操作数据库 | 渐进采用 Wow CQRS + Event Sourcing | 传统架构迁移 | Wow v6 的版本兼容假设 |
| 使用精确平台基线的 Wow v6 | 使用固定目标平台的 Wow v8 | Wow v6 迁移到 v8 | 重新设计全部业务边界 |
| 已在 Wow v8 上自定义 Dispatcher、MessageBus 或 Spring 生命周期 | 当前统一 WowRuntime | 运行时编排迁移 | 业务数据重写 |
文档边界
| 文档 | 负责回答 | 核心源码依据 |
|---|---|---|
| 传统架构迁移 | 如何从 CRUD 建立 command、aggregate、event、state，并安全切流？ | CreateOrder.kt:31-64、Order.kt:55-137 |
| v6 → v8 | 如何按精确 v6 平台基线对齐固定 v8 目标，并处理存储与 API 破坏？ | v6.21.5 版本基线、v8.0.0 Release、当前版本基线 |
| 运行时编排迁移 | 如何把多个生命周期 owner 收敛到一个 WowRuntime？ | WowAutoConfiguration.kt:118-152 |
共同完成门禁
无论选择主路径还是运行时编排专项，都应按证据推进，而不是以“应用能启动”作为完成标准。
- 范围：固定 bounded context、数据集、版本起点、目标版本与明确不迁移的内容。
- 基线：记录测试结果、事件/快照数量、关键业务指标和可回滚备份。
- 验证：执行单元测试、集成测试、逐聚合对账、代表性事件回放和真实启动/停机。
- 发布：先单实例或小流量验证，明确新写入出现后的回滚数据处理方式。
- 关闭：观察窗结束后再清理旧数据、旧 writer、兼容代码和临时同步链路。
旧链接导航
原迁移页中的主题已分别移动到 传统架构迁移、 Wow v6 迁移到 v8 和 运行时编排迁移。以下标题和别名完整保留原页面 的深链接；到达后请继续进入对应的新页面。
版本升级指南
参见 v6 → v8：通用升级步骤。
从传统架构迁移
参见 传统架构迁移：迁移总览。
数据迁移
代码迁移
参见 传统架构迁移：先迁移边界，不先迁移表 和 对账后分别切换读与写。
兼容性说明
参见 传统架构迁移：领域模型继续演进 和 v6 → v8：破坏性变更检查。
已知问题
参见 Release Notes 和 故障排查。
迁移检查清单
参见 传统架构迁移检查清单 或 v6 → v8 验证清单。
回滚计划
参见本页共同完成门禁，以及所选迁移页面的切换和回滚步骤。
统一运行时编排
参见 运行时编排迁移。
移除版本化快照检查点
SnapshotStore 原子保存
参见 v6 → v8：SnapshotStore 原子保存。
Redis EventStore Canonical v2 布局（v8.9.0 引入）
参见 v6 → v8：Redis EventStore Canonical v2 布局。
Mongo 所有权保护
相关页面
| 页面 | 关系 |
|---|---|
| 传统架构迁移 | 首次采用 Wow |
| Wow v6 迁移到 v8 | 已使用 Wow 的平台升级 |
| 运行时编排迁移 | v8 生命周期扩展迁移 |
| 故障排查 | 验证失败时的定位入口 |