Разработка SaaS для обратной совместимости с данными и бизнес-логикой

Question

У меня есть платформа SaaS, где пользователь заполняет форму и данные, введенные в форму, сохраняются в базе данных. Пользовательский интерфейс формы имеет большое количество настроек (происходит из БД, но заканчивается в JavaScript) и бизнес-логики (в JavaScript). После того, как форма заполнена и сохранена, пользователь может в любой момент вернуться и отредактировать ее.

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

Для подтверждения новые формы, заполненные пользователем, будут, конечно, использовать новую / текущую схему данных и бизнес-логику. Но предыдущие формы должны вести себя так же, как и при создании.

Поэтому мне нужен разумный способ настройки версий, бизнес-логики и любых зависимостей.

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

Для бизнес-логики я сохраняю номер версии системы вместе с записью, например, "01". Когда пользователь загружает старую форму, я проверяю версию записи и затем загружаю JavaScript формы из пути, например, "js/main_01.js". Когда я делаю не обратно совместимое изменение в бизнес-логике, я увеличиваю номер версии системы, например, до "02". Новые формы будут использовать "js/main_02.js". Я также использую этот дешевый подход к версиям HTML-шаблонов, который становится проблематичным.

Этот подход работает, но кажется немного надуманным или доморощенным. Я пытаюсь избежать условностей в моей бизнес-логике, как if version==2: do this, Этот подход избегает этого, но также имеет свои недостатки.

Я не думаю, что стек действительно имеет значение для этого convo, но на всякий случай я использую django/mysql.

Answer 1

Вы, вероятно, получите огромное количество "мнений" по этому вопросу, и не получите однозначного четкого ответа.

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

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