Из вашего описания причина, по которой существующее приложение нуждается в рефакторинге, заключается в том, что оно было построено на основе функциональных требований, а аспекты балансировки нагрузки и доступности были проигнорированы. Так как они не были приняты во внимание в первоначальном проекте приложения, приложение теперь должно быть переработано. Различные воздействия высокой доступности и балансировки нагрузки на дизайн приложения не становились проблемами до тех пор, пока клиент не попытался реализовать их для приложения, не предназначенного для них.
Что вы предлагаете, так это выполнить редизайн нового приложения без учета аспектов аварийного восстановления. Это точно та же ошибка, что была допущена во время первой реализации, только на этот раз игнорируемыми требованиями являются аспекты DR. Что вы будете делать, когда перейдете к дизайну DR и обнаружите, что в вашем недавно переработанном приложении есть непредвиденные пробелы и дефекты в функциональности, которые конфликтуют с дизайном DR?
Прежде чем касаться какого-либо кода в этом задании, вам необходимо очень хорошо понять требования клиента к восстановлению, а затем разработать приложение с учетом этих требований. Вы должны знать цель времени восстановления, цель точки восстановления, как приложение будет согласовывать свое состояние с любыми восходящими или нисходящими приложениями (и является ли это ручным или автоматическим согласованием), влияние лицензирования на сайт горячего / теплого / холодного аварийного восстановления и т. д. и т. д. В противном случае вы вводите необоснованный риск и возможность значительных переделок в дальнейшем.