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

Question

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

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

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

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

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

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

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

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

Answer 1

Вы, вероятно, получите огромное количество «мнений» по этому вопросу, и нет реального ясного ответа.

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

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