👥 Подходы к версионированию с учётом многопользовательского режима.

💾 Большинство IDE в АСУ ТП - это десктопные приложения, которые рассчитаны на работу одного пользователя. Проект - набор бинарных файлов, версионирование и слияния затруднены даже с использованием системы контроля версий, если она не встроена глубоко внутрь IDE. Необходимость работы над проектом в команде - боль с постоянной пересылкой через облако и дописыванием "_V10" в конец файла.

📸 Большинство IDE реализуют сохранение при помощи снапшотов (контрольных точек). Весь проект сериализуется в большой JSON/XML, который кладется в папку проекта или базу данных. Если в таких системах поддержан многопользовательский режим, то он основан на слиянии, как в системах контроля версий вроде Git. Один пользователь передает свою версию проекта другому, IDE построчно сравнивает внутреннее представление. Отдельное веселье с десериализацией, например, чтобы отобразить разницу между разными версиями одной FBD-диаграммы.

👩‍💻 Можно ли организовать одновременное редактирование проекта несколькими пользователями в реальном времени с сохранением истории изменений? На практике это потребует реализации следующих механизмов: 1. История изменений проекта 2. Версионирование и откат изменений 3. Разрешение конфликтов при одновременном редактировании

📌 Про разрешение конфликтов напишу как-нибудь в следующий раз. Особая сложность возникает при реализации истории и версионирования. На ум приходит как минимум 2 варианта реализации.

📦 Первый наиболее дешёвый и простой - использовать встроенные механизмы СУБД. Например CDC (Change Data Capture) или System-Versioned Tables. База данных хранит все записи, которые утратили актуальность и эти записи могут быть использованы для восстановления определенной версии проекта. Но есть нюанс - действия пользователя могут изменить сразу несколько записей базы, например, переименование переменной также изменит все диаграммы, где используется эта переменная.

🚀 Такой подход можно реализовать быстро и он не требует высокой квалификации от команды. Из недостатков - база данных быстро вырастет в размере из-за накопленной истории, это как минимум создаст трудности при экспорте/импорте проекта со всей историей. Если исторические данные не отделить от актуальных, то размер базы приведет к деградации производительности. Также приложение становится зависимым от вендора выбранной СУБД.

⛓️ Альтернативный подход называется Event Sourcing, ближайшая аналогия - СVS, когда хранится оригинальный файл и набор diff'ов к нему. Хранится не набор состояний проекта, а история изменений в виде доменных событий. На практике этот подход почти всегда реализуется совместно с Domain Driven Design (DDD). Если все сделать правильно, то архитектура приложения получается намного чище, и появляется возможность абстрагироваться от использования конкретной СУБД при помощи паттерна репозиторий (Repository).

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

⚖️ Выбор между этими вариантами - это вопрос зрелости команды и жизненного цикла продукта. Первый вариант подойдет для MVP, но для платформы, рассчитанной на долгую эволюцию не всегда стоит идти самым простым путем.