Автор статьи в Stack Overflow Blog предлагает снова всерьёз обсудить модельно-ориентированное программирование: подход, в котором модель предметной области становится не схемой для презентации, а рабочей основой для создания и сопровождения системы. Повод не корпоративный анонс и не релиз нового фреймворка: это манифест разработчика, который 13 лет назад создал язык и IDE Mo+ и теперь считает, что именно эпоха ИИ делает идею особенно своевременной.
По данным Stack Overflow Blog, автор применял Mo+ в собственных и корпоративных проектах, но не смог вывести технологию на широкий рынок. Шесть лет назад он ушёл из разработки и занялся строительством кораблей эпохи викингов и англосаксов, однако к теме моделей продолжал возвращаться. В новой публикации он зовёт университеты и компании исследовать класс языков, который, по его мнению, пока почти не представлен в индустрии.
В центре концепции — жёсткое разделение структуры модели и её данных. Структура задаёт иерархию узлов и атрибутов: один корневой узел, дочерние элементы и ссылки между ними. Данные заполняют эту структуру. Автор отдельно спорит с привычной реакцией на реляционные схемы: таблицы и внешние ключи выглядят как граф, но для его подхода сама схема базы данных — это данные, размещённые в более общей иерархии «база — таблица — столбец — ключ». Перекрёстные связи предлагается хранить как атрибуты-ссылки на другие узлы.
На примере сети ресторанов статья показывает разницу между моделью требований и программным кодом. В модели есть ресторан, сотрудники, посетители, блюда и связи между ними. Но важны не сами сущности — их можно описать десятком способов, — а то, что одна и та же модель должна стать доступной языку как формальная среда исполнения. В таком сценарии разработчик не создаёт вручную классы для обхода метамодели: язык уже знает, что такое сущность, свойство и связь, потому что они входят в его грамматику на время программной сессии.
Автор делит model-oriented development на четыре формы. Неформальная — это доска, блокнот и диаграммы, которые не понимают инструменты. Inline-подход знаком большинству команд: модель живёт в коде, а фреймворк использует её для конкретного слоя приложения. В качестве примеров названы ORM Entity Framework и NHibernate, а также Angular и React. Coupled-подход напоминает UML-инструменты, где элементы модели тесно соответствуют исходникам. Самой перспективной автор считает decoupled-модель: требования и данные описываются отдельно от конкретных классов, сервисов, таблиц и интерфейсов, а код может использовать эту модель для генерации и поддержки системы.
Отсюда следует важное ограничение, о котором в статье говорят прямо: это не призыв заменить объектно-ориентированные языки универсальной «модельной магией». Для переходного варианта MOP модель на время сессии загружается и становится неизменяемым снимком. Затем язык обходит её и создаёт целевую среду: исходники на другом языке, конфигурации или документы. В целевом варианте язык уже работает непосредственно внутри системы; в моделирующем — помогает собирать и обновлять саму модель.
Техническая ставка сделана на три механики. Первая — динамическая грамматика: узлы и атрибуты модели добавляются к синтаксису языка при запуске сессии. Вторая — контекст модели, в том числе стек контекстов, который позволяет обращаться к текущему узлу, его родителю, потомкам и элементам всей модели без создания вспомогательных объектов. Третья — «модельные свойства»: независимые фрагменты кода, прикреплённые к типу узла. Например, свойство для сущности может сгенерировать объявление класса, а свойство для атрибута — строку свойства; вместе они собирают файл класса для каждой сущности модели.
Для практикующих разработчиков здесь нет готового инструмента, который можно поставить в проект в понедельник утром. Но есть полезная рамка для разговора о генерации кода, DSL, метамоделях и агентной разработке. ИИ уже умеет писать код по описанию, однако обычно это описание остаётся текстом с неоднозначностями, а результат требует ручной сверки. Формальная модель могла бы стать общим контрактом между бизнес-требованиями, генераторами и кодовой базой — при условии, что её поддержка не окажется дороже самой разработки.
Модельно-ориентированное программирование пока выглядит скорее исследовательским направлением и личной инженерной программой автора, чем складывающимся рынком. Но вопрос поставлен точно: если команды всё чаще поручают машинам преобразовывать требования в код, не пора ли сделать сами требования исполнимыми, проверяемыми и менее зависимыми от того, как именно очередная модель ИИ прочитала человеческий текст?