Промты для системного аналитика и архитектора: проектируем API, БД и микросервисы до первой строки кода

Промты для системного аналитика и архитектора: проектируем API, БД и микросервисы до первой строки кода

Проектирование архитектуры — это этап, где ошибки стоят дороже всего. Неверно выбранная схема БД, неучтённые нефункциональные требования или плохо спроектированный API могут привести к переписыванию системы через полгода. По данным исследования IBM, стоимость исправления дефекта на этапе проектирования в 100 раз ниже, чем на этапе эксплуатации. Именно поэтому системные аналитики и архитекторы ищут способы ускорить и улучшить этот процесс.

Сегодня LLM уже не просто генерируют текст — они могут выступать в роли эксперта-архитектора, помогая формулировать требования, проектировать контракты API, строить ER-диаграммы и декомпозировать монолит на микросервисы. Но чтобы получить действительно полезный результат, нужны правильно составленные промты. В этой подборке — 10 проверенных промтов, которые я использую в реальных проектах. Каждый из них экономит дни работы и снижает риск архитектурных ошибок.

1. Сбор и формализация требований: превращаем хаос в структуру

Задача: Есть сырые заметки со встреч с заказчиком, набор хотелок и противоречивых пожеланий. Нужно превратить это в структурированный список функциональных и нефункциональных требований.

Промт:

Ты — опытный системный аналитик. У тебя есть следующие заметки со встречи с заказчиком:

[ВСТАВИТЬ ТЕКСТ ЗАМЕТОК]

Твоя задача:
1. Выделить функциональные требования (что система должна делать).
2. Выделить нефункциональные требования (производительность, безопасность, доступность и т.д.).
3. Указать противоречия и неясности, которые требуют уточнения.
4. Предложить способ разрешения каждого противоречия.
5. Оформить результат в виде таблицы: ID, Тип, Описание, Приоритет (MoSCoW), Комментарий.

Формат ответа: таблица Markdown.

Пример результата:

На каком этапе экономит: Сбор требований. Вместо 2–3 дней ручного анализа — 30 минут на проверку и уточнение.

2. Проектирование REST API: генерируем OpenAPI-спецификацию

Задача: Нужно спроектировать REST API для сервиса управления задачами. Требуется OpenAPI-спецификация с эндпоинтами, схемами запросов и ответов.

Промт:

Ты — архитектор API. Спроектируй REST API для сервиса управления задачами (task tracker).

Требования:
- Ресурсы: задачи, проекты, пользователи.
- CRUD для каждого ресурса.
- Аутентификация через JWT.
- Пагинация, фильтрация и сортировка для списков.
- Версионирование через URL (/api/v1/).

Выдай OpenAPI 3.0 спецификацию в формате YAML.

Пример результата (фрагмент):

openapi: 3.0.0
info:
  title: Task Tracker API
  version: 1.0.0
paths:
  /api/v1/tasks:
    get:
      summary: Получить список задач
      parameters:
        - name: page
          in: query
          schema:
            type: integer
            default: 1
        - name: limit
          in: query
          schema:
            type: integer
            default: 20
      responses:
        '200':
          description: Успешный ответ
          content:
            application/json:
              schema:
                type: array
                items:
                  $ref: '#/components/schemas/Task'

На каком этапе экономит: Проектирование API. Позволяет за 15 минут получить черновик спецификации, который обычно занимает полдня.

3. Проектирование схемы базы данных: от ER-диаграммы до DDL

Задача: Спроектировать схему БД для интернет-магазина с учётом связей, индексов и ограничений.

Промт:

Ты — эксперт по проектированию баз данных. Спроектируй схему PostgreSQL для интернет-магазина.

Сущности: пользователи, товары, категории, заказы, позиции заказов, платежи.
Требования:
- Нормализация до 3НФ.
- Внешние ключи с каскадным удалением где необходимо.
- Индексы для часто запрашиваемых полей.
- Комментарии к таблицам и колонкам.

Выдай:
1. ER-диаграмму в формате Mermaid.
2. DDL-скрипт для создания таблиц.

Пример результата (фрагмент):

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    email VARCHAR(255) UNIQUE NOT NULL,
    password_hash VARCHAR(255) NOT NULL,
    created_at TIMESTAMP DEFAULT NOW()
);

CREATE TABLE orders (
    id SERIAL PRIMARY KEY,
    user_id INT REFERENCES users(id) ON DELETE CASCADE,
    status VARCHAR(50) NOT NULL,
    total_amount DECIMAL(10,2) NOT NULL,
    created_at TIMESTAMP DEFAULT NOW()
);

На каком этапе экономит: Проектирование БД. Вместо ручного написания DDL и диаграмм — генерация за минуты.

4. Диаграммы последовательностей: визуализируем сценарии

Задача: Описать взаимодействие компонентов при оформлении заказа.

Промт:

Ты — системный архитектор. Построй диаграмму последовательности (sequence diagram) для процесса оформления заказа в интернет-магазине.

Участники: Пользователь, API Gateway, Order Service, Payment Service, Inventory Service, Notification Service.

Опиши шаги: создание заказа, резервирование товара, оплата, уведомление.

Формат: Mermaid sequenceDiagram.

Пример результата:

sequenceDiagram
    User->>API Gateway: POST /orders
    API Gateway->>Order Service: createOrder()
    Order Service->>Inventory Service: reserveItems()
    Inventory Service-->>Order Service: reserved
    Order Service->>Payment Service: processPayment()
    Payment Service-->>Order Service: paymentSuccess
    Order Service->>Notification Service: sendConfirmation()
    Order Service-->>API Gateway: orderCreated
    API Gateway-->>User: 201 Created

На каком этапе экономит: Проектирование взаимодействий. Быстрое создание диаграмм для документации.

5. Декомпозиция монолита на микросервисы

Задача: Разбить монолитное приложение на микросервисы с учётом bounded context.

Промт:

Ты — архитектор микросервисов. Проанализируй монолитное приложение (описание ниже) и предложи декомпозицию на микросервисы.

[ОПИСАНИЕ МОНОЛИТА]

Шаги:
1. Выдели bounded context по Domain-Driven Design.
2. Предложи список микросервисов с зонами ответственности.
3. Определи способы взаимодействия (синхронные/асинхронные).
4. Укажи возможные проблемы и способы их решения (распределённые транзакции, eventual consistency).

Формат: таблица + пояснения.

Пример результата:

На каком этапе экономит: Архитектурное проектирование. Ускоряет анализ и выбор стратегии декомпозиции.

6. Генерация технического задания для команды

Задача: Написать ТЗ для разработчиков на основе требований и архитектуры.

Промт:

Ты — технический писатель. Составь техническое задание для команды разработки на основе следующих требований и архитектурных решений:

[ВСТАВИТЬ ТРЕБОВАНИЯ И АРХИТЕКТУРУ]

Структура ТЗ:
1. Цель и область применения.
2. Функциональные требования.
3. Нефункциональные требования.
4. Архитектура системы (диаграммы).
5. Описание API.
6. Схема БД.
7. План работ и этапы.

Формат: Markdown.

На каком этапе экономит: Документирование. Сокращает время на написание ТЗ с дней до часов.

7. Аудит архитектуры: поиск узких мест

Задача: Проверить существующую архитектуру на соответствие best practices и выявить риски.

Промт:

Ты — Senior архитектор. Проведи аудит архитектуры системы (описание ниже).

[ОПИСАНИЕ АРХИТЕКТУРЫ]

Проверь:
- Соответствие принципам SOLID, DDD.
- Наличие единых точек отказа.
- Проблемы с масштабируемостью и производительностью.
- Безопасность (OWASP Top 10).
- Стоимость владения.

Выдай отчёт: список проблем, риски, рекомендации.

Пример результата:
- Проблема: Единая база данных для всех сервисов. Риск: Связанность, сложность масштабирования. Рекомендация: Перейти на database-per-service.
- Проблема: Отсутствие кэширования. Риск: Высокая нагрузка на БД. Рекомендация: Внедрить Redis для горячих данных.

На каком этапе экономит: Аудит и оптимизация. Быстрое выявление проблем без долгих воркшопов.

8. Проектирование gRPC API

Задача: Создать gRPC-сервис для высоконагруженного взаимодействия.

Промт:

Ты — эксперт по gRPC. Спроектируй gRPC API для сервиса аутентификации.

Требования:
- Методы: Register, Login, ValidateToken.
- Использовать protobuf3.
- Стриминг для ValidateToken (stream).

Выдай .proto файл и пример реализации на Go.

Пример результата:

syntax = "proto3";
package auth;

service AuthService {
  rpc Register (RegisterRequest) returns (RegisterResponse);
  rpc Login (LoginRequest) returns (LoginResponse);
  rpc ValidateToken (stream ValidateRequest) returns (stream ValidateResponse);
}

message RegisterRequest {
  string email = 1;
  string password = 2;
}

На каком этапе экономит: Проектирование API. Генерация proto за минуты.

9. Выбор технологического стека

Задача: Обосновать выбор технологий для нового проекта.

Промт:

Ты — технологический консультант. Помоги выбрать стек для проекта: высоконагруженный сервис аналитики в реальном времени.

Критерии: производительность, масштабируемость, стоимость, скорость разработки.

Предложи 3 варианта стека, сравни их в таблице, дай рекомендацию.

Пример результата:

Рекомендация: Вариант 1 для максимальной производительности.

На каком этапе экономит: Выбор стека. Быстрое сравнение и обоснование.

10. Генерация тест-кейсов для API

Задача: Создать тест-кейсы для проверки API.

Промт:

Ты — QA-инженер. На основе OpenAPI-спецификации (ниже) сгенерируй тест-кейсы для API.

[ВСТАВИТЬ OPENAPI]

Покрой: позитивные сценарии, негативные, граничные значения, безопасность.

Формат: таблица с шагами и ожидаемым результатом.

Пример результата:

На каком этапе экономит: Тестирование. Ускоряет подготовку тестов.

11. Проектирование событийной архитектуры (Event-Driven)

Задача: Спроектировать событийную архитектуру для системы уведомлений.

Промт:

Ты — архитектор событийных систем. Спроектируй event-driven архитектуру для системы уведомлений.

Требования:
- События: UserRegistered, OrderCreated, PaymentProcessed.
- Брокер: Kafka.
- Гарантия доставки: at-least-once.
- Схема событий: Avro.

Выдай:
1. Список топиков и схемы событий.
2. Диаграмму потоков.
3. Пример продюсера и консьюмера на Python.

Пример результата:

from kafka import KafkaProducer
import json

producer = KafkaProducer(bootstrap_servers='localhost:9092',
                         value_serializer=lambda v: json.dumps(v).encode('utf-8'))

producer.send('user-registered', {'user_id': 123, 'email': 'user@example.com'})

На каком этапе экономит: Проектирование событий. Быстрое создание схем и примеров.

12. Оценка трудозатрат и планирование спринтов

Задача: Оценить трудозатраты на разработку по требованиям.

Промт:

Ты — тимлид. Оцени трудозатраты на разработку проекта на основе требований (ниже).

[ВСТАВИТЬ ТРЕБОВАНИЯ]

Разбей на задачи, оцени в story points, предложи план спринтов (2 недели).

Формат: таблица задач с оценками + диаграмма Ганта.

Пример результата:

На каком этапе экономит: Планирование. Ускоряет оценку и распределение.

Заключение

Промты для системного аналитика и архитектора — это не замена экспертизе, а инструмент, который усиливает её. Они позволяют быстрее проходить рутинные этапы, генерировать черновики и проверять гипотезы. Однако важно помнить: LLM может ошибаться, поэтому критически оценивайте каждый результат. Используйте эти промты как отправную точку для диалога, адаптируйте под свой контекст и всегда проверяйте факты.

Попробуйте применить хотя бы один из промтов в текущем проекте — и вы увидите, как рутинные задачи проектирования занимают минуты вместо часов. А если хотите глубже освоить системный анализ и архитектуру с использованием AI, изучите наши курсы на asibiont.com — там мы разбираем реальные кейсы и делимся продвинутыми техниками.