Да, абсолютно верно. В некотором смысле так было всегда: либо мы сначала изменяем описание системы и затем приводим реализацию в соответствие с ним, либо меняем код, после чего актуализируем описание.
Полностью устранить эту двойственность, вероятно, невозможно, если описание поведения не является одновременно исполняемой моделью. Но хочется хотя бы сократить объём ручных действий, необходимых для поддержания этих представлений в согласованном состоянии.
При этом дополнительный архитектурный слой полезен ещё до генерации кода. Он выступает валидируемой моделью, на которой архитектор может заранее проверить структуру системы, допустимость связей, контракты взаимодействия и архитектурные ограничения. То есть часть ошибок и противоречий можно обнаружить ещё до появления реализации.
Особенно это важно, если мы движемся в сторону агентной разработки. Хочется не просто передавать агенту репозиторий и надеяться, что он правильно восстановит замысел системы, а явно задавать ему архитектурный контекст, ответственность конкретного узла и ограничения, в пределах которых он должен работать.
Более того, агент может использовать этот слой не только как контекст для изменения кода. Он может предлагать или вносить изменения и в саму архитектуру. Поскольку архитектурная модель формализована и валидируется, такие изменения можно проверить до генерации или модификации реализации.
Таким образом, задача этого слоя — не стать единственным источником истины для всей бизнес-логики, а сделать разработку более контролируемой: уменьшить стоимость синхронизации описания и кода, сузить пространство решений для агента и позволить валидировать архитектурные изменения до того, как они превратятся в код.
В текущей реализации используется двусторонний вариант, и он уже работает для той структуры, которая задаётся фреймворком.
Из графа можно сгенерировать Go-сервис(ы). Если затем разработчик вручную изменит в коде поддерживаемую фреймворком структуру, её можно извлечь обратно и загрузить в дизайнер.
При этом речь не идёт о восстановлении всей программы или произвольной бизнес-логики. Сейчас извлекаются узлы графа, связи между ними, семантика вызовов и частично информация о контрактах. Кастомный код внутри узлов остаётся обычным Go-кодом и обратно в граф не преобразуется.
Причём граф намеренно не опускается до деталей реализации контрактов — например, до конкретного набора полей структуры. Для него важен сам тип контракта и его роль во взаимодействии между узлами. Детальное описание поведения конкретного узла, бизнес-правил и внутренней логики остаётся задачей архитектора. Именно эта информация должна дополнять архитектурный граф и служить исходным контекстом для AI-агента, который затем использует её при реализации конкретной функциональности. Иными словами, граф отвечает на вопрос «как устроена система», а архитектор — «что должен делать каждый узел».
Поэтому это не полный round-trip для Go-кода, а двусторонняя синхронизация той части архитектурной структуры, которая выражена через примитивы фреймворка. Случайные детали реализации при таком извлечении в граф попадать не должны, поскольку анализируется не произвольный код, а только известные фреймворку конструкции.
Information
Rating
1,051-st
Registered
Activity
Specialization
Бэкенд разработчик, Архитектор программного обеспечения
Да, абсолютно верно. В некотором смысле так было всегда: либо мы сначала изменяем описание системы и затем приводим реализацию в соответствие с ним, либо меняем код, после чего актуализируем описание.
Полностью устранить эту двойственность, вероятно, невозможно, если описание поведения не является одновременно исполняемой моделью. Но хочется хотя бы сократить объём ручных действий, необходимых для поддержания этих представлений в согласованном состоянии.
При этом дополнительный архитектурный слой полезен ещё до генерации кода. Он выступает валидируемой моделью, на которой архитектор может заранее проверить структуру системы, допустимость связей, контракты взаимодействия и архитектурные ограничения. То есть часть ошибок и противоречий можно обнаружить ещё до появления реализации.
Особенно это важно, если мы движемся в сторону агентной разработки. Хочется не просто передавать агенту репозиторий и надеяться, что он правильно восстановит замысел системы, а явно задавать ему архитектурный контекст, ответственность конкретного узла и ограничения, в пределах которых он должен работать.
Более того, агент может использовать этот слой не только как контекст для изменения кода. Он может предлагать или вносить изменения и в саму архитектуру. Поскольку архитектурная модель формализована и валидируется, такие изменения можно проверить до генерации или модификации реализации.
Таким образом, задача этого слоя — не стать единственным источником истины для всей бизнес-логики, а сделать разработку более контролируемой: уменьшить стоимость синхронизации описания и кода, сузить пространство решений для агента и позволить валидировать архитектурные изменения до того, как они превратятся в код.
В текущей реализации используется двусторонний вариант, и он уже работает для той структуры, которая задаётся фреймворком.
Из графа можно сгенерировать Go-сервис(ы). Если затем разработчик вручную изменит в коде поддерживаемую фреймворком структуру, её можно извлечь обратно и загрузить в дизайнер.
При этом речь не идёт о восстановлении всей программы или произвольной бизнес-логики. Сейчас извлекаются узлы графа, связи между ними, семантика вызовов и частично информация о контрактах. Кастомный код внутри узлов остаётся обычным Go-кодом и обратно в граф не преобразуется.
Причём граф намеренно не опускается до деталей реализации контрактов — например, до конкретного набора полей структуры. Для него важен сам тип контракта и его роль во взаимодействии между узлами. Детальное описание поведения конкретного узла, бизнес-правил и внутренней логики остаётся задачей архитектора. Именно эта информация должна дополнять архитектурный граф и служить исходным контекстом для AI-агента, который затем использует её при реализации конкретной функциональности. Иными словами, граф отвечает на вопрос «как устроена система», а архитектор — «что должен делать каждый узел».
Поэтому это не полный round-trip для Go-кода, а двусторонняя синхронизация той части архитектурной структуры, которая выражена через примитивы фреймворка. Случайные детали реализации при таком извлечении в граф попадать не должны, поскольку анализируется не произвольный код, а только известные фреймворку конструкции.