Как на Python описать архитектуру сервисов и превратить её в код

[a1oleg]

Я создал прототип, укладывающий код в граф. Рекомендую для ознакомления https://habr.com/ru/articles/1087078/

[itGuevara]

"описать архитектуру сервисов" - есть примеры когда это делают на RDF\OWL (вкл. онтологию как предметной области, так и frontend), или хотя бы описание UI (структура окошек и взаимодействие)?

Видимо должны появиться новые ai-языки для vibecoding на базе BPMN. Не попадались? Практичнее более верхнеуровневая надстройка, а не python\js\c.

[gorundebug]

RDF/OWL для описания предметной области встречал, но у меня задача немного другая: не построить универсальную онтологию системы, а описать исполняемую топологию — типизированные потоки данных, контракты узлов, связи, транспорт и границы сервисов — так, чтобы из этой модели можно было генерировать рабочий код для разных runtime.

Python здесь скорее язык сборки модели, а не язык самой архитектуры. Получившаяся модель от Python не зависит: сейчас из неё генерируются сервисы на Go, C++, Rust, Python и TypeScript. Поэтому теоретически сверху вполне может появиться и BPMN-подобный редактор, и AI-язык, и вообще другой DSL — если они транслируются в ту же модель.

С UI пока в эту модель не лезу. Мне кажется, там уже появляется другой набор сущностей и семантика взаимодействия, и я бы скорее связывал отдельную UI-модель с моделью сервисов через контракты, чем пытался описывать всё одной онтологией.

На более верхнеуровневые AI/BPMN-языки тоже смотрю с интересом. Я бы только разделял язык, удобный человеку/агенту для описания намерения, и достаточно строгую промежуточную модель, которую уже можно валидировать и из которой можно воспроизводимо генерировать код. У меня Service Architect сейчас как раз скорее про второй слой.

[itGuevara]

Я бы только разделял язык, удобный человеку/агенту для описания намерения, и достаточно строгую промежуточную модель, которую уже можно валидировать и из которой можно воспроизводимо генерировать код. 

Описание данных, алгоритмов (преобразований), да и интерфейсов (в крупную клетку) на RDF + онтологии (для каждого направления своя), далее логика "грубо" через базовые функции + SPARQL в направлении SPARQL-driven Programming и уже "шлифовка" vibecode (review только DSL \ SPARQL). Конечно принцип Model-first, включая детальную модель данных (в составе онтологии). Только исходная модель не совсем исполняемая, а только частично (каркас).

[gorundebug]

Понял. Получается, у нас общий Model-first подход, но разная граница исполнения.

У вас RDF/OWL задают более богатую семантическую модель, а SPARQL уже частично используется как язык логики поверх неё.

У меня модель уже: типы, потоки, контракты, связи и транспорт. Зато описанная часть ближе к execution IR: из неё можно воспроизводимо генерировать сервисы для разных runtime, сохраняя одинаковую семантику, но выражая её идиоматично для каждого из них. Бизнес-логика остаётся обычным кодом, потому что на уровне архитектуры мы обычно не опускаемся до деталей её реализации.

То есть у вас модель шире по смыслу, у меня — уже, но ближе к исполнению.

[gorundebug]

Спасибо, посмотрел — интересно. У нас, похоже, довольно близкая цель, но движение идёт с разных сторон.

У вас получается примерно код → AST → граф → диаграммы/контекст: граф восстанавливается из существующей кодовой базы и становится индексом структуры и зависимостей.

У меня направление скорее обратное: архитектурная модель → граф → сгенерированный код. Существенные связи, типы, потоки и границы сервисов задаются явно до генерации, а реализации бизнес-функций остаются обычным кодом.

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

Я проводил эксперимент: дал агенту большой проект RTB платформы и попросил построить DSL на питоне. После нескольких уточнений он достаточно хорошо это сделал. Ему хорошо помогал валидатор и то, что можно было сгенерировать проект и скомпилировать его (это добавляло ему понимания). По началу он пошел переносить в граф AST очень подробно. Но потом я ему задал более четкие границы и получилось достаточно не плохо.