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

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

不幸的是，与许多单片应用程序一样，这个应用程序为每个用户交互维护一组非常大的状态数据，并且必须在用户通过功能进行操作时进行维护

我的问题是，我可以通过哪些方式负责任地满足混合遗留/非遗留体系结构，以便在未来状态下，所有新的单个应用程序都无望地依赖于此共享状态模型

---

我最初的想法是将状态数据写入某种缓存中，这种缓存既可供遗留应用程序访问，也可供新应用程序访问，以便它们可以协调工作，直到新应用程序拥有独立运行所需的基础设施。我对这种方法非常怀疑，因此我希望得到一些反馈或以新的方式来看待这个问题。

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

拆分组件后，开始将数据写入新旧数据库

用旧数据库中需要的任何内容回填新数据库

验证两者具有相同的数据

将依赖此部分数据的所有内容更改为从新组件/数据库中读取

更改依赖此部分数据的所有内容以写入新组件/数据库

弃用旧数据库中的数据，即。备份它，然后将其删除。这将确认您已迁移该块

---

优点是不应该有数据丢失或功能丢失，您有时间测试您为组件选择的每个数据模型，看看它是否与应用程序流一起工作。分割一块巨石可能很棘手，决定你的有界上下文位于何处是至关重要的，而且没有完美的科学。始终记住需要应用程序扩展的地方以及需要执行的部分。

是的，这正是我的想法，尽管我没有停用任何遗留数据库，因为它们在整个公司都在使用（不幸的是），但我只是停用应用程序。因此，由于它的会话数据寿命很短，因此只需对新数据库进行一次写入，但将遵循迁移的其余步骤。