Представьте, что вы пишете приложение с базой данных. Но без 1С. Но вам хочется, чтобы было примерно похоже, с той же простотой.
Как бы вы задавали модель данных? Все что у вас есть - это Visual Studio Code и платформа, которая прочитает некий файл/скрипт/whatever и воспримет это, как модель базы данных…
По мне так JSON, если читаемость будет не очень, то XML Schema.
А дальше "Новый ОбъектМетаданныхКонфигурация(“структура.json”) 
Я более детально имел в виду. JSON - это всего-лишь способ описания некоторого ИКС. А что внутри ИКС? Будет ли это один файл на базу, или много файлов, по одному на сущность? А может это будет код на os, а не декларативный файл?
Попробуйте представить, что вы создаете базу. Как выглядит идеальный процесс?
На вскидку:
Создаем JSON описываем параметры подключения и структуру базы. Думаю, что многие также выскажутся за наличие визуального инструмента для генерации JSON.
Я ровно про это спрашиваю: Как?
Т.е. формат описать? Или чем их генерить?
Думаю так
Как работать
Поясни, что есть процесс сборки?
Тут наверное должен быть класс работы с базой (также с подключаемыми плагинами под разные СУБД).
Ты хочешь разыменование таблиц / Полей?
Свой или SQL-xx?
Мне видится как некоторая функциональность движка, когда разработчик может сказать “мое приложение скомпилься / установись”, то по имеющимся настройкам базы происходит обновление схем.
Язык - я бы выбрал поддержку ansi SQL как базовую (дабы не придумывать), при необходимости подключая расширения других БД.
Зачем так: приложение может поддерживать хранение в любой СУБД, в зависимости от желания пользователя, тогда основная функциональность будет единой.
Я вот тут тебе не совсем понял. Ты имеешь ввиду, что база уже есть и ты из нее вытягиваешь схему?
Тут, да, я выше про это тоже писал, про плагины.
База может как быть, тогда надо вытяную ее схему и обновить, так и не существовать - тогда следовательно создать и настроить.
Я любитель магии. Ты создаёшь класс, говоришь, что он реализует интерфейс/наследует класс/имеет аннотацию модели, над нужными свойствами аннотациями устанавливаешь типы и дополнительные необходимые свойства колонок таблицы.
Под каждую таблицу отдельный класс.
Все остальное берет на себя движок/либа. В когфигах указан способ подключения к субд. Стартуем приложение, выполняем метод инициализации и/или миграций, движок проверяет классы с аннотациями, создаёт/модифицирует таблицы, заливает их данными при необходимости (seed)
Пока не забыл и не вылетело из головы @EvilBeaver
у меня есть мысли на этот счет, но они скажем так “визионерские”. Суть в том что у сущности есть несколько поведенческих моделей
если с первыми все понятно - создание,чтение, обновление и удаление
то со вторыми чуть сложней
а с третьим вообще очень сложно, потому как инновационно.
сущность не обязательно должна хранится в sql базе - размышления привели к тому что хранилище сущности может быть
sql, nosql, fts (full text search), agregate
то есть что я имею ввиду
МодельРасходнойНакладной = Новый Модель("РасходнаяНакладаная);
МодельРасходнойНакладной.Версия(1);
МодельРасходнойНакладной.ИспользоватьХранилищеSQL(
ТипыSQL.Postgres, ПодключенныеХранилища.ПолучитьПодключение("pg-prod-master")
);
МодельРасходнойНакладной.ИспользоватьХранилищеNOSQL(
ТипыNOSQL.MongoDB, ПодключенныеХранилища.ПолучитьПодключение("mongo-master")
);
МодельРасходнойНакладной.ИспользоватьХранилищеFTS(
ТипыFTS.Elastic, ПодключенныеХранилища.ПолучитьПодключение("elastic-master")
);
МодельРасходнойНакладной.ИспользоватьХранилищеАгрегатов(
ТипыHOLAP.ClickHouse, ПодключенныеХранилища.ПолучитьПодключение("clickhouse-master")
);
Попытка
МодельРасходнойНакладной.ИспользоватьКласс("src/model/РасходнаяНакладная.os")
Исключение
ВызватьИсключение("Класс не соответствует определению модели: Подробно
|" + ОписаниеОшибки())
КонецПопытки;
Фактически каждое хранилище для своего, что позволит очень долго не проваливатся в физику СУБД - оставаясь долго на уровне логики поведения модели 
Да, в целом так и есть. А еще можно вспомнить про модный CQRS