Не так давно в нашем блоге была статья о том, как искусственный интеллект помогает разбирать логи 1C. В этой — поговорим о задачах архитекторов ПО. LLM и диффузионные модели уже способны генерировать варианты архитектур, оценивать компромиссы и предлагать решения быстрее, чем это возможно вручную. Пора разобраться, насколько глубоко ИИ может встроиться в рабочие процессы архитектора ПО — и стоит ли ему там оставаться.
Привет, Хабр! Меня зовут Александр Брейман, я доцент департамента программной инженерии факультета компьютерных наук НИУ ВШЭ и по совместительству старший преподаватель Учебного центра IBS. В этой статье расскажу про большие языковые модели в приложении к работе архитектора ПО. Вместе мы посмотрим, насколько хорошо GPT понимает ИТ-архитектуру и сможет ли уже сегодня заменить архитектора.
Какую модель выбрать?
Большие языковые модели делятся на коммерческие (OpenAI, Anthropic, Google и другие) и открытые (DeepSeek, Qwen, LLaMA, Mistral и другие) модели.
Плюсы коммерческих моделей очевидны:
-
высокая производительность из «коробки» (особенно на сложных задачах);
-
простота доступа (API, веб-интерфейсы);
-
большое окно контекста;
-
нахождение на пике технологий (мультимодальность и прочее);
-
меньшие затраты на инфраструктуру, если использовать облачные API.
С открытыми моделями тоже все понятно — они бесплатны и, что немаловажно, доступны в России без VPN. В числе минусов открытых моделей обычно называют кражу данных, но, я думаю, мы все понимаем, что ChatGPT точно так же обучается на всех загруженных промптах, как и DeepSeek.
Я тестировал большинство современных моделей и сейчас, как правило, пользуюсь открытыми LLM. Больше всего радуют Qwen от Alibaba (не зря на нее перешел YandexGPT) и DeepSeek. Для проработки корпоративной архитектуры и для кодирования еще очень хорошо подходит свежая версия гугловского Gemini 2.5, а вот новая LLaMA 4, на мой взгляд, особого внимания не заслуживает. Под программирование сильно заточен Claude Sonnet, а с текстовыми документами лучше работает Claude Opus.
Критерии выбора LLM для рабочих проектов
-
Конфиденциальность: если нужен контроль за чувствительными данными — а в корпоративных проектах это обычно главный вопрос, то выбор один — открытая модель на локальном сервере.
-
Бюджет: за API придется заплатить, но его проще начать, тогда как опенсорс потребует самостоятельной интеграции и инвестиций в инфраструктуру, но может быть дешевле в масштабе.
-
Эффективность: для сложнейших задач лучше выбирать коммерческие модели, но на практике с большинством вопросов справляются и открытые решения с минимальной донастройкой.
-
Кастомизация: если требуется дообучение на своих данных, то выбираем открытые модели. При этом важно иметь в команде соответствующую экспертизу для поддержки.
В целом выбор зависит от задачи, требований к безопасности и ресурсов. Часто оптимальна гибридная стратегия.
LLM как инструмент архитектора
Работу современного архитектора ПО можно разбить на шесть групп задач:
-
Анализ требований и выявление противоречий в спецификациях.
-
Проектирование и оценка архитектурных решений.
-
Создание и обновление технической документации.
-
Разработка API-спецификаций и контрактов.
-
Оценка технического долга и рефакторинг.
-
Генерация диаграмм и схем архитектуры.
Чтобы понять, как LLM справляются с работой архитектора, я сформулировал конкретные промпты и оценил ответы нейросети по каждой из этих задач. Дабы не раздувать статью до слишком больших размеров, приложил не все ответы, а лишь некоторые.
Задача 1. Анализ требований
Архитектор ПО работает с огромным количеством документации — ТЗ, пользовательские истории, спецификации — требования могут быть разбросаны по разным документам или разделам. Ручной анализ десятков, а то и сотен страниц текста — это трудоемкий процесс, требующий значительного времени. Противоречия — например, между функциональными и нефункциональными требованиями — не всегда очевидны с первого взгляда, естественный язык допускает разные трактовки и может приводить к неоднозначной интерпретации, а у человека при этом может элементарно «замылиться» взгляд.
Как с этой задачей поможет нейросеть? Мы можем использовать LLM для первичного анализа текстовых требований и быстрой идентификации потенциальных проблем и скрытых конфликтов в документации.
Что можно спросить у LLM:
-
Найти неясные или двусмысленные формулировки: «Какие фразы могут быть истолкованы по-разному?»
-
Выявить прямые противоречия: «Есть ли требования, которые конфликтуют друг с другом?»
-
Обнаружить недостающую информацию: «Чего не хватает для полного понимания этого требования?»
-
Сгруппировать связанные требования: «Собери все требования, относящиеся к модулю аутентификации».
-
Задать уточняющие вопросы: «Какие вопросы стоит задать заказчику по этому пункту?»
Анализ требований — запрос 1
Проанализируй следующие требования из спецификации на систему управления заказами. Найди возможные противоречия или неясности:
Система должна позволять Менеджеру изменять статус заказа на «Отменен» в любое время до момента его передачи в службу доставки.
После того как Пользователь оплатил заказ, статус заказа автоматически меняется на «Оплачен» и не может быть изменен Менеджером вручную для предотвращения мошенничества.
Менеджер должен иметь возможность отменить любой заказ по запросу клиента, даже если он уже оплачен, но еще не отправлен.
Анализ требований — ответ нейросети 1
Обнаружены потенциальные противоречия и неясности:
Прямое противоречие (Требования 2 и 3)
Требование 2 запрещает Менеджеру изменять статус после оплаты, а Требование 3 разрешает Менеджеру отменять оплаченный (но не отправленный) заказ. Необходимо уточнить, какой процесс имеет приоритет или как обрабатывается отмена оплаченного заказа (возврат средств, изменение статуса и т. д.).
Неясность (Требование 1 и 3)
Требование 1 ограничивает отмену моментом передачи в доставку. Требование 3 также упоминает «еще не отправлен». Являются ли «передача в службу доставки» и «отправлен» синонимами в данном контексте? Нужно единое определение.
Потенциальный конфликт (Требование 1 и 2)
Если оплата происходит до передачи в доставку, то Требование 2 (автоматическая блокировка изменения статуса после оплаты) может конфликтовать с Требованием 1 (возможность отмены до передачи в доставку). Нужно определить последовательность и условия изменения статусов.
Понятно, что при наличии всего трех требований эти противоречия мы могли бы легко найти и своими глазами, но вот когда их сотня, то помощь ИИ уже кажется по-настоящему ценной. С этой задачей нейросеть справилась на ура.
Анализ требований — запрос 2
Проанализируй следующее нефункциональное требование (NFR) для новой системы отчетности. Укажи на неясности, недостающую информацию и предложи вопросы, которые помогут сделать это требование измеримым и тестируемым:
NFR-05. Система должна обеспечивать быстрый доступ к генерируемым отчетам.
Анализ требований — ответ нейросети 2
Анализ требования «NFR-05. Система должна обеспечивать быстрый доступ к генерируемым отчетам» выявил следующие неясности и недостающую информацию:
Неопределенность термина «быстрый»
«Быстрый» является субъективным понятием. Для одного пользователя это 1 секунда, для другого — 10 секунд.
Вопрос: Какое максимальное время от запроса отчета до его отображения пользователю считается приемлемым (в секундах или миллисекундах)?
Отсутствие контекста нагрузки
Производительность системы может сильно зависеть от количества одновременных пользователей или сложности отчета.
Вопросы: При какой нагрузке (например, количество одновременных пользователей, объем данных в отчете) должно выполняться требование по времени отклика? Это требование для среднего времени отклика или для 95-го перцентиля?
Неясность определения «доступ к отчетам»
Что именно включает в себя «доступ»? Только генерацию? Или генерацию + загрузку? Или открытие уже сгенерированного отчета?
Вопросы: Какая конкретно операция должна быть «быстрой»? Генерация нового отчета? Открытие существующего? Экспорт отчета?
Отсутствие критериев измеримости
Текущая формулировка не позволяет объективно проверить выполнение требования.
Вопрос: Как будет измеряться и проверяться выполнение этого требования? Какие инструменты будут использоваться?
Нейросеть мгновенно нашла пробелы в требованиях и сформулировала готовые наводящие вопросы, избавив нас от рутины.
Анализ требований — запрос 3
Проанализируй следующую User Story на предмет полноты. Какие потенциальные вопросы возникают? Какие ключевые Acceptance Criteria (AC) могут быть пропущены?
Как зарегистрированный пользователь я хочу иметь возможность загружать аватар в свой профиль, чтобы другие пользователи могли меня узнать.
Анализ требований — ответ нейросети 3
Анализ данной User Story выявил потенциальные вопросы и недостающие Acceptance Criteria (AC):
Возникающие вопросы:
Форматы файлов: Какие форматы изображений для аватара поддерживаются (JPEG, PNG, GIF)?
Размер файла: Есть ли ограничение на максимальный размер загружаемого файла (в МБ)?
Размеры изображения: Есть ли ограничения на минимальные/максимальные размеры изображения (в пикселях)? Что происходит, если изображение слишком большое/маленькое?
Обрезка/Редактирование: Предоставляется ли пользователю инструмент для кадрирования (обрезки) аватара после загрузки?
Замена аватара: Что происходит при загрузке нового аватара? Старый удаляется? Хранится история?
Удаление аватара: Может ли пользователь удалить аватар, оставив изображение по умолчанию? Что является изображением по умолчанию?
Ошибки: Как система информирует пользователя об ошибках (неверный формат, превышен размер и т.д.)?
Место отображения: Где именно будет отображаться этот аватар (в профиле, в комментариях, в списке пользователей)?
Потенциально пропущенные Acceptance Criteria (AC):
AC1: Пользователь может выбрать файл изображения со своего устройства через стандартный диалог выбора файла.
AC2: Система проверяет формат файла (принимает только .jpg, .png).
AC3: Система проверяет размер файла (не более 5 МБ).
AC4: [Если есть кадрирование] Пользователь видит превью и может обрезать изображение перед сохранением.
AC5: После успешной загрузки пользователь видит свой новый аватар на странице профиля.
AC6: При попытке загрузить неподдерживаемый формат файла пользователь видит сообщение об ошибке [текст ошибки].
AC7: При попытке загрузить файл большего размера пользователь видит сообщение об ошибке [текст ошибки].
AC8: Пользователь может удалить текущий аватар, после чего отображается аватар по умолчанию.
Итог: User Story понятна на высоком уровне, но требует детализации через уточняющие вопросы и добавление конкретных AC для полного понимания и тестирования функциональности.
Отличный развернутый ответ. Нейросеть снова на высоте.
Задача 2. Проектирование и оценка решений
Проектирование и оценка решений — запрос 1
Мы проектируем систему обработки событий для IoT-платформы, ожидается высокий поток данных (сотни тысяч сообщений в секунду) от устройств. Данные нужно надежно доставить нескольким независимым сервисам-обработчикам (аналитика, мониторинг, хранение). Порядок событий важен в рамках одного устройства.
Сравни Kafka и RabbitMQ для этого сценария. Укажи ключевые плюсы и минусы каждого в контексте задачи (пропускная способность, гарантии порядка, модель потребления, масштабируемость).
Не буду копировать длинный ответ нейросети, скажу лишь, что и с этой задачей она справилась — расписала преимущества и недостатки обоих решений и сделала вывод, что под нашу задачу лучше подойдет Kafka ввиду более простой масштабируемости.
Проектирование и оценка решений — запрос 2
Я проектирую взаимодействие между микросервисом «Заказы» и микросервисом «Уведомления». Когда статус заказа меняется на «Отправлен», сервис «Уведомления» должен отправить email клиенту. Этот процесс может иногда занимать время или временно быть недоступным, и он не должен блокировать основной поток обработки заказа. Какой паттерн взаимодействия (синхронный REST API вызов или асинхронный через очередь сообщений) лучше подходит? Обоснуй кратко.
Проектирование и оценка решений — запрос 3
Мы выбираем базу данных для хранения каталога товаров в e-commerce системе. Структура товара может меняться (разные атрибуты для разных категорий: у ноутбука — процессор, у футболки — размер/цвет). Ожидается высокая нагрузка на чтение (просмотр каталога) и необходимость гибкого поиска/фильтрации по разным атрибутам. Сравни реляционную БД (например, PostgreSQL) и документо-ориентированную NoSQL БД (например, MongoDB или Elasticsearch) для этой задачи. Укажи плюсы и минусы в контексте гибкости схемы, производительности чтения и возможностей поиска.
Со вторым и третьим запросом нейросеть также справилась без проблем. Перейдем к более сложной задаче — генерации решений.
Задача 3. Документация
Генерация ADR — запрос
Сгенерируй Architecture Decision Record (ADR) в формате Markdown, используя стандартный шаблон (Статус, Контекст, Решение, Последствия).
Тема: Выбор асинхронного взаимодействия через брокер сообщений для уведомления пользователей.
Статус: Принято
Контекст: Сервису «Заказы» необходимо уведомлять сервис «Уведомления» об изменении статуса заказа (например, «Отправлен»), чтобы тот мог отправить email клиенту. Прямой синхронный вызов (REST) может блокировать обработку заказа и чувствителен к временной недоступности сервиса «Уведомления». Требуется отказоустойчивое и слабо связанное решение.
Рассмотренные альтернативы: 1. Синхронный REST вызов от «Заказов» к «Уведомлениям». 2. Прямая запись в БД сервиса «Уведомления» (нарушение инкапсуляции). 3. Асинхронное взаимодействие через брокер сообщений (Kafka/RabbitMQ).
Решение: Использовать асинхронное взаимодействие. Сервис «Заказы» публикует событие OrderShippedEvent в топик брокера сообщений. Сервис «Уведомления» подписывается на этот топик и обрабатывает события. Выбран брокер Apache Kafka из-за требований к потенциальной высокой нагрузке и возможности перечитывания событий.
Мы пунктирно описали задачу, контекст, какое решение было выбрано, почему оно было выбрано, какие альтернативы рассматривали и почему от них отказались. Нейросеть легко генерирует разумное ADR и может даже подсказать другие альтернативы.
README — запрос
Создай структуру основного README.md файла для нового микросервиса «Payment Service”.
Ключевая информация:
Назначение: Обработка входящих платежей через интеграцию с платежным шлюзом.
Технологии: Java 17, Spring Boot 3, Maven, PostgreSQL, Docker.
Основные API эндпоинты (примеры): POST /payments (создать платеж), GET /payments/{id} (получить статус).
Как запустить локально: Использовать docker-compose up.
Сгенерируй базовую структуру с основными разделами.
Нейросеть генерирует базовую документацию README для репозитория с описанием, о чем вообще этот микросервис, на чем он сделан, какие у него эндпоинты и как его запускать. Это еще одна рутинная задача, которую можно спокойно переложить на ИИ.
Задача 4. Генерация OpenAPI
Генерация OpenAPI — запрос
Сгенерируй фрагмент спецификации OpenAPI 3.0 в формате YAML для описания эндпоинта получения информации о пользователе по его ID.
Путь: /users/{userId}
Метод: GET
Параметр пути: userId (тип: строка, формат: uuid, обязательный)
Успешный ответ (200 OK): Объект User со полями id (uuid), username (string), email (string, format: email), createdAt (string, format: date-time).
Ответ при ошибке (404 Not Found): Стандартный ответ «Пользователь не найден».
Краткое описание (summary): «Получить информацию о пользователе по ID».
Тег: Users
Я задал краткое поверхностное описание — и нейросеть сгенерировала нормальную «простыню» OpenAPI. Если на проекте API-first подход, когда API формируется до кода, а не наоборот, то автогенерация через ИИ сильно упрощает жизнь. Да, возможно, придется что-то по минимуму подправить или дописать, но в целом никаких особых «галлюцинаций» у нейросети здесь не возникает.
Генерация примера запроса/ответа — запрос
Опиши пример JSON-тела запроса и пример JSON-ответа (201 Created) для API эндпоинта POST /api/v1/orders.
Описание запроса: Создание нового заказа. Должен содержать ID пользователя (строка, uuid), список заказанных товаров (массив объектов, каждый с productId (строка) и quantity (число > 0)) и адрес доставки (объект с полями street, city, zipCode).
Описание ответа (201): Должен содержать ID созданного заказа (строка, uuid) и его текущий статус (строка, значение по умолчанию «PENDING»).
Поскольку большинство LLM учили на Python и JavaScript, нейросети отлично знают эти два языка и выдают хорошие ответы в формате JSON. Кстати, опыт показывает, что если прописать сам промпт в виде JSON, то модель воспримет его еще лучше и выдаст еще более качественный структурированный результат в том же формате.
Задача 5. Рефакторинг
Рефакторинг — запрос
Опиши основные стратегии рефакторинга для следующей ситуации:
У нас есть большой класс OrderProcessor в монолитном приложении. Он отвечает за:
Валидацию данных нового заказа.
Проверку наличия товаров на складе (прямой запрос к таблице склада).
Резервирование товаров на складе (прямой update таблицы склада).
Расчет итоговой стоимости с учетом скидок (сложная логика скидок внутри).
Создание записи о заказе в БД заказов.
Инициацию процесса оплаты через вызов PaymentService.
Отправку уведомления пользователю (вызов NotificationService).
Класс стал очень большим (~2000 строк), его сложно тестировать и изменять.
Какие подходы к рефакторингу можно применить, чтобы улучшить его структуру и снизить связанность?
Разумный запрос, на который нейросеть выдает весьма разумный ответ. Опять же, копировать не буду, чтобы не делать бесконечный лонгрид.
Задача 6: Диаграммы
Диаграммы PlantUML — запрос
Сгенерируй код для диаграммы компонентов PlantUML, описывающий взаимодействие в системе онлайн-заказов:
Компоненты:
Веб-интерфейс пользователя (UI)
API Gateway
Сервис Заказов (Order Service)
Сервис Продуктов (Product Service)
База данных Заказов (Orders DB)
База данных Продуктов (Products DB)
Взаимодействия:
UI использует API Gateway.
API Gateway направляет запросы к Сервису Заказов и Сервису Продуктов.
Сервис Заказов взаимодействует с Базой данных Заказов.
Сервис Заказов также может запрашивать информацию у Сервиса Продуктов (например, для проверки цены).
Сервис Продуктов взаимодействует с Базой данных Продуктов.
Используй стандартные обозначения компонентов и интерфейсов, если возможно.
Сделай Сервис Заказов центральным элементом.
Большие языковые модели отлично знают PlantUML, так что при грамотных вводных, с указанием компонентов и взаимодействий, без проблем генерируют код для диаграммы.
Диаграммы Mermaid — запрос
Сгенерируй код для диаграммы последовательности Mermaid, иллюстрирующий процесс создания нового заказа.
Участники: Клиент (User), API Gateway, Сервис Заказов (OrderService), Сервис Склада (InventoryService).
Последовательность действий:
Клиент отправляет запрос POST /orders на API Gateway с данными заказа.
API Gateway перенаправляет запрос на Сервис Заказов.
Сервис Заказов валидирует запрос.
Сервис Заказов отправляет запрос на Сервис Склада для резервирования товаров (reserveItems).
Сервис Склада отвечает Сервису Заказов (успех/неудача резервирования).
Если резервирование успешно, Сервис Заказов создает заказ в своей БД (пометь это как внутреннее действие).
Сервис Заказов отвечает API Gateway (статус 201 Created с ID заказа).
API Gateway отвечает Клиенту (статус 201 Created).
То же самое — LLM понимают устройство диаграмм Mermaid и выдают результат в хорошем текстовом формате. Полдела сделано — нам останется только визуализировать диаграмму.
Промпт как ТЗ: проектируем архитектуру вместе с нейросетью
Теперь попробуем набросать высокоуровневую микросервисную архитектуру для простого e-commerce сайта в диалоге с LLM. Для решения этой задачи я решил использовать веб-интерфейс модели с открытым исходным кодом DeepSeek.
Идентификация сервисов
Я проектирую микросервисную архитектуру для e-commerce платформы. Предложи основные функциональные домены/микросервисы, которые понадобятся.
Поскольку такого рода задачи все большие языковые модели видели много раз, результат будет максимально типовым. В принципе, это нормально — дальше мы всё равно будем его отшлифовывать. Но если развернуть ТЗ чуть более подробно и сразу задать нейросети роль, то и ответ получится гораздо более точным.
Ты — эксперт по проектированию микросервисных архитектур. Твоя задача — помочь идентифицировать набор микросервисов для системы на основе предоставленных требований.
Контекст:
Мы разрабатываем систему для онлайн-платформы по продаже билетов на мероприятия (концерты, спектакли, фестивали). Платформа должна поддерживать следующие ключевые функции:
1. Регистрация и аутентификация пользователей.
2. Поиск мероприятий по различным критериям (дата, место, жанр).
3. Просмотр деталей мероприятия (описание, участники, расписание).
4. Бронирование и покупка билетов.
5. Управление заказами пользователя (просмотр истории, отмена заказов).
6. Интеграция с платежными системами.
7. Аналитика продаж для организаторов мероприятий.
Требования к архитектуре:
Каждый микросервис должен быть независимым и решать одну конкретную бизнес-задачу.
Микросервисы должны взаимодействовать через хорошо определенные API.
Архитектура должна быть масштабируемой и отказоустойчивой.
Задача:
На основе описанных требований предложи список микросервисов, которые необходимы для реализации этой системы. Для каждого сервиса укажи:
1. Название сервиса.
2. Его основную ответственность (бизнес-функцию).
3. Основные операции (например, CRUD или специфические действия).
4. Какие другие сервисы он может использовать или с которыми взаимодействовать.
Результат представь в виде структурированного списка.
Чтобы еще больше упростить себе задачу, можно сначала сформировать такого рода промпт с помощью этой же или любой другой модели, а потом его же ей и «скормить». Важно, чтобы промпт был структурирован и разбит на пункты — LLM такое очень любят.
Детализация одного сервиса
Давай сфокусируемся на сервисе «Заказы». Какие у него ключевые обязанности (ответственности)? Какие основные API-эндпоинты ему могут понадобиться (CRUD операций достаточно для примера)?
Можно ограничиться таким простеньким запросом — текущие версии LLM все равно выдадут что-то вполне приличное. Если же мы хотим получить не самый типовой вариант, то детализируем запрос:
Ты — эксперт по проектированию микросервисных архитектур. Твоя задача — помочь детализировать микросервис OrderService для системы онлайн-продажи билетов на мероприятия.
Контекст:
OrderService отвечает за управление заказами пользователей. Заказы включают информацию о выбранных билетах, статусе оплаты и истории покупок. Сервис должен быть независимым, но взаимодействовать с другими микросервисами для выполнения своих функций.
Известные интеграции:
1. TicketService: Управляет билетами (бронирование, покупка, отмена).
2. PaymentService: Обрабатывает платежи через внешние платежные системы.
3. EventCatalogService: Предоставляет информацию о мероприятиях.
Требования к OrderService:
Сервис должен поддерживать CRUD-операции для заказов.
Должен предоставлять API для просмотра истории заказов пользователя.
Должен обрабатывать изменения статуса заказа (например, «создан», «оплачен», «отменен»).
Должен быть отказоустойчивым и масштабируемым.
Задача:
На основе предоставленного контекста предложи детальное описание OrderService, включая:
1. Основные сущности (Entity), которые будут использоваться в сервисе.
2. CRUD-операции и дополнительные действия (например, изменение статуса заказа).
3. API-методы (в формате OpenAPI или простом текстовом описании).
4. Взаимодействие с другими сервисами (какие запросы отправляются и какие данные получены).
5. Возможные расширения функциональности (например, уведомления о статусе заказа).
Результат представь в виде структурированного описания.
По сути, мы взаимодействуем с нейросетью как с младшим помощником. Если выдать джуну ТЗ на пару предложений, что-нибудь вменяемое он, вероятно, и выдаст. Но если сразу дать все вводные и подробно объяснить, что ты хочешь от него получить, результат будет более рабочим.
Взаимодействие сервисов
Простой запрос:
Как сервис «Заказы» должен взаимодействовать с сервисом «Пользователи» (для получения данных о клиенте) и сервисом «Каталог» (для проверки цен/наличия)? Предложи варианты (синхронно/асинхронно, REST/события) и кратко обоснуй.
Развернутый запрос:
Ты — эксперт по проектированию микросервисных архитектур. Твоя задача — помочь описать взаимодействие между тремя микросервисами: OrderService, UserService и EventCatalogService в рамках системы онлайн-продажи билетов на мероприятия.
Контекст:
1. OrderService: Управляет заказами пользователей, включая создание, просмотр и изменение статуса заказов.
2. UserService: Отвечает за регистрацию, аутентификацию и управление данными пользователей (например, профиль пользователя).
3. EventCatalogService: Хранит информацию о мероприятиях (описание, расписание, доступность билетов).
Сценарии использования:
1. Пользователь регистрируется или авторизуется в системе.
2. Пользователь ищет мероприятия через EventCatalogService.
3. Пользователь создает заказ на покупку билетов.
4. Система проверяет доступность билетов и подтверждает бронирование.
5. Пользователь оплачивает заказ, и система обновляет статус заказа.
6. Пользователь может просматривать историю своих заказов.
Задача:
На основе предоставленного контекста предложи детальное описание взаимодействия между сервисами, включая:
1. Последовательность вызовов API между сервисами для каждого сценария использования.
2. Основные запросы и ответы (в виде примеров JSON или текстового описания).
3. Какие данные передаются между сервисами и как они используются.
4. Возможные точки отказа и способы обеспечения отказоустойчивости.
Результат представь в виде последовательного описания для каждого сценария использования.
Визуализация
Простой запрос:
Сгенерируй Mermaid диаграмму (component diagram), показывающую сервисы «Пользователи», «Каталог», «Заказы» и их основные синхронные взаимодействия (REST API), которые мы обсудили.
Развернутый запрос:
Ты — эксперт по проектированию микросервисных архитектур и созданию технической документации. Твоя задача — помочь создать Mermaid-диаграмму для визуализации взаимодействия между микросервисами в системе онлайн-продажи билетов на мероприятия.
Контекст:
1. AuthService/UserService: Отвечает за регистрацию, аутентификацию и управление данными пользователей.
2. EventCatalogService: Хранит информацию о мероприятиях (описание, расписание, доступность билетов).
3. OrderService: Управляет заказами пользователей, включая создание, просмотр и изменение статуса заказов.
4. TicketService: Управляет билетами (бронирование, покупка, отмена).
5. PaymentService: Обрабатывает платежи через внешние платежные системы.
Сценарий взаимодействия:
1. Пользователь авторизуется в системе через AuthService.
2. Пользователь ищет мероприятие через EventCatalogService.
3. Пользователь создает заказ на покупку билетов через OrderService.
4. OrderService взаимодействует с TicketService для бронирования билетов.
5. OrderService инициирует платеж через PaymentService.
6. После успешной оплаты OrderService обновляет статус заказа и сохраняет его.
Задача:
На основе предоставленного контекста сгенерируй Mermaid-диаграмму (типа sequenceDiagram), которая визуализирует взаимодействие между сервисами для описанного сценария. Убедись, что:
1. Диаграмма показывает последовательность вызовов между сервисами.
2. Каждый шаг взаимодействия четко обозначен (например, «Пользователь -> AuthService: Авторизация»).
3. Используются корректные названия сервисов и операций.
Результат представь в виде готового Mermaid-кода.
Что важно учесть при общении с моделью
LLM хорошо работает в диалоге, поэтому исходный промпт можно и нужно уточнять. Четкость и контекст в запросе = лучший результат. Фокус помогает быстрее перейти от идеи к конкретным структурированным артефактам — API и диаграммам.
Но здесь есть такой момент: все самые важные ключевые слова должны быть прописаны в самом начале запроса. Матрицы внимания нейросети реагируют на исходный промпт и дальше отталкиваются именно от него. Если вдруг вы в начале сказали что-то лишнее или вообще сформулировали задачу неправильно, то сойти с этих рельсов, переключить внимание LLM уже не получится — придется сбрасывать весь диалог и начинать общение с нуля.
Еще один лайфхак: ключевые слова из исходного промпта можно повторять по ходу дела — таким образом вы подтверждаете их важность для нейросети.
Выводы
Конечно, чтобы нейросеть выдавала качественно иные результаты и мыслила как сеньор, нужно проделать большую предварительную работу — построить семантические структуры, графы знаний, загрузить всю документацию в отдельную векторную базу и отсылать модель к ней как к источнику данных о контексте проекта. Если сделать все «по красоте», то нейросеть сможет сосредоточиться на особенностях конкретного проекта вместо того, чтобы креативить в типовом вакууме.
Тем не менее даже если мы ограничимся такими простыми запросами, какие я дал в статье, от ИИ уже будет большая польза. На данном этапе развития нейросетей ИИ — уже не хайп и генератор хаоса, а полноценный рабочий инструмент и помощник для архитектора ПО. Он ускоряет рутину в работе с документацией, API и диаграммами и помогает в творческих задачах брейншторминга, оценки требований и решений.
При этом полностью доверить нейросети создание архитектуры пока нельзя. Критическое мышление и валидация человеком — обязательны. Ответы нейросети не идеальны и требуют проверки, критики и доработки архитектором. ИИ на сегодняшний день все еще умный ассистент, а не замена человека.
ссылка на оригинал статьи https://habr.com/ru/articles/1024020/