Приложение для новой отрасли собирается из настроек, а не пишется заново

Экраны, данные, права доступа и процессы описаны файлами настроек. Чтобы запустить продукт для другой отрасли, не нужно копировать и переписывать код.

Задача

На одной основе запускать приложения для разных отраслей — экспедирование грузов, автосервис — не копируя код.

Решение

Экраны, данные, права доступа и процессы описаны в файлах настроек. Из готовых блоков — таблица, форма, поле, кнопка, вкладки, меню — собирается интерфейс; там же описаны маршруты, сущности, кто что видит, запросы к данным и переводы.

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

Результат

157 модулей в основе, 60 модулей и 218 процессов в отраслевом приложении, ещё одно приложение на 14 модулей. Новая отрасль подключается настройками.

Второе применение того же подхода

Принцип тот же, что в системе учёта перевозок, задача другая: там настройками описаны процессы, здесь — экраны, данные и права.

Как устроено

Почему так, а не иначе — где подход упирается в предел

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

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

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

Третья — читаемость. Файл настроек на несколько сотен строк перестаёт быть проще кода, и его начинают копировать вместо того, чтобы переиспользовать.

Вывод, который я забираю в любой проект: настройками стоит описывать то, что правда меняется часто и людьми без разработчика. Всё остальное дешевле оставить кодом.

Другие кейсы

Кейсы и личные проекты

Три сайта, кабинет клиента и система учёта перевозокВитрина, калькулятор доставки, личный кабинет и система, которая ведёт перевозку от заказа до счёта. Обычно такие проекты делают разные команды. Здесь я участвовал в каждой части.Кабинет клиента: покупки, отправления, платежи и документы в одном местеОдин кабинет вместо переписки с менеджерами: увидеть, где посылка, оплатить, скачать документ. Один и тот же код обслуживает два разных сервиса — различия лежат в настройках.Система учёта международных перевозок: от заказа до счёта клиентуЧерез систему проходит перевозка целиком — заказы, доставка самолётом и морем, объединение грузов, тарифы, счета, кредитные лимиты, комиссии агентов. Процессы описаны настройками, поэтому меняются без выпуска версии.