architecture - 在从单一遗留应用程序增量迁移中处理状态数据

Question

我有一个非常大的单体遗留应用程序，我的任务是在不同的架构上分解许多上下文受限的应用程序。我的管理层正在推动新旧应用程序协同工作，直到所有遗留功能都迁移到当前架构。

不幸的是，与许多单体应用程序的情况一样，这个应用程序为每个用户交互维护了一组非常大的状态数据，并且必须随着用户在功能上的进展而进行维护。

我的问题是有哪些方法可以负责任地满足混合遗留/非遗留架构的要求，以便在未来状态下所有新的单个应用程序都无可救药地依赖于这种共享状态模型？

我最初的想法是将状态数据写入某种类型的缓存中，该缓存可供旧应用程序和新应用程序访问，以便它们可以协调工作，直到新应用程序具有独立运行所需的基础架构。我对这种方法持怀疑态度，因此我希望得到一些反馈或看待问题的新方法。

标签： architectureenterprise

Answer 1

每当我处理这种情况时，我都会对数据采用双写方法，因为它主要是数据迁移问题。当您拆分每个功能时，您实际上将拥有两个数据模型，直到完全弃用旧模型。基本步骤是：

1. 拆分组件后，开始将数据写入旧数据库和新数据库。
2. 用旧数据库中所需的任何内容回填新数据库。
3. 验证两者具有相同的数据。
4. 将依赖这部分数据的所有内容更改为从新组件/数据库中读取。
5. 更改依赖这部分数据的所有内容以写入新组件/数据库。
6. 弃用旧数据库中的数据，即 备份它然后删除它。这将确认您已迁移该块。

优点是不应该有数据丢失或功能丢失，并且您有时间测试您为组件选择的每个数据模型，以查看它是否适用于应用程序流。分割一块巨石可能会很棘手，因为确定有界上下文的位置很关键，而且没有完美的科学。始终牢记您需要在哪里扩展应用程序以及需要执行哪些部分。