работа с данными состояния в пошаговом переходе от унаследованного монолитного приложения

Question

У меня есть очень большое монолитное унаследованное приложение, которое мне поручено разбить на множество контекстно-зависимых приложений на другой архитектуре. Мое руководство настаивает на том, чтобы старые и новые приложения работали в тандеме, пока все устаревшие функции не будут перенесены в текущую архитектуру.

К сожалению, как и в случае со многими монолитными приложениями, этот поддерживает очень большой набор данных о состоянии для каждого взаимодействия с пользователем, и его необходимо поддерживать по мере продвижения пользователя по функциональности.

У меня вопрос, каким образом я могу ответственно удовлетворить гибридную унаследованную / не унаследованную архитектуру, чтобы в будущем все новые отдельные приложения безнадежно зависели от этой модели общего состояния?

Моя первоначальная мысль - записать данные о состоянии в какой-то кэш-память, доступную как устаревшим приложениям, так и новым приложениям, чтобы они могли работать в гармонии до тех пор, пока новые приложения не будут иметь инфраструктуру, необходимую для независимой работы. Я очень скептически отношусь к этому подходу, поэтому я хотел бы получить обратную связь или новые взгляды на проблему.

Answer 1

Всякий раз, когда я сталкиваюсь с этой ситуацией, я использую подход двойной записи данных, поскольку это в основном проблема переноса данных. Разделяя каждую часть функциональности, вы фактически получите две модели данных, пока устаревшая модель полностью не устареет. Основные шаги для этого:

1. После выделения компонента начните записывать данные как в старую, так и в новую базу данных.
2. Залейте в новую базу данных все, что вам нужно из старой.
3. Убедитесь, что оба имеют одинаковые данные.
4. Измените все, что зависит от этой части данных, для чтения из нового компонента / базы данных.
5. Измените все, что зависит от этой части данных, для записи в новый компонент / базу данных.
6. Устаревать эти данные в старой базе данных, т. Е. поддержите это тогда удалите это. Это подтвердит, что вы перенесли этот кусок.

Преимущество заключается в том, что не должно быть потери данных или потери функциональности, и у вас есть время протестировать каждую модель данных, которую вы выбрали для компонента, чтобы выяснить, работает ли он с потоком приложений. Разрезать монолит может быть сложно, решив, где лежат ваши ограниченные контексты, очень важно, и для этого нет совершенной науки. Всегда помните, где необходимо масштабировать приложение и какие части требуются для его выполнения.