**Роль:** Ты — бизнес-аналитик и технический архитектор. Твоя задача — прочитать код как историю (story), понять бизнес-процесс, а затем создать детальную архитектурную карту.
**Задача:** Проанализируй код метода `Handle` в файле `` и всю связанную с ним логику. Сначала **пойми бизнес-сценарий**, а затем **построй карту выполнения**.
**Ограничения:**
- НЕ анализируй файлы с суффиксом `*_test.go` — они содержат тесты и не отражают реальную бизнес-логику.
- Игнорируй все файлы моков (например, `mock_*.go`, `*_mock.go`, папки `mocks/`, `test/mocks/` и т.п.).
- Анализируй только основной код (`*.go` в папках `internal/`, `pkg/`, `service/`, `handler/`, `api/` и т.п.).
### **ШАГ 1: АНАЛИЗ БИЗНЕС-СЦЕНАРИЯ (Человеческим языком)**
Прочитай код и ответь:
1. **Кто является пользователем этой системы?** (Другие сервисы, администраторы, cron-задание?)
2. **Какой бизнес-проблему решает этот код?**
- Что было ДО запуска этого процесса?
- Что происходит ВО ВРЕМЯ выполнения?
- Что изменится ПОСЛЕ успешного выполнения?
3. **Какие бизнес-объекты участвуют?** (Пользователи, скидки, сегменты, программы лояльности?)
4. **Каковы ключевые бизнес-правила?**
- Когда нужно обновлять данные?
- Какие данные считаются "разными"?
- Что делать с устаревшими данными?
**Формат ответа на ШАГ 1:**
```
БИЗНЕС-СЦЕНАРИЙ:
1. Пользователь: [описание]
2. Проблема: [что решает]
3. Объекты:
- [Объект 1]: [роль в процессе]
- [Объект 2]: [роль в процессе]
4. Бизнес-правила:
- Правило 1: [описание + где в коде]
- Правило 2: [описание + где в коде]
```
### **ШАГ 2: ВЫЯВЛЕНИЕ ПОТОКА ДАННЫХ (Data Flow Analysis)**
Теперь проанализируй код технически:
1. **Откуда берутся данные?** Найди все источники данных:
- Базы данных (DWH, PostgreSQL, Redis)
- API других сервисов
- Входные параметры
- Конфигурационные файлы
2. **Куда данные попадают?** Найди все приемники данных:
- Внешние API
- Базы данных
- Логи
- Очереди сообщений
3. **Как данные трансформируются?** Найди ключевые преобразования:
- Фильтрация
- Группировка
- Сравнение
- Агрегация
### **ШАГ 3: ПОСТРОЕНИЕ КАРТЫ ВЫПОЛНЕНИЯ (Execution Mapping)**
Создай детальную карту по следующему шаблону:
**A. ПОЛНАЯ ЦЕПОЧКА ВЫЗОВОВ (от начала до конца):**
```
1. [Точка входа] → [Первый вызов]
├── [Что проверяется/решается]
└── [Условия перехода к следующему шагу]
2. [Второй шаг] → [Вызов метода]
├── [Источник данных]
├── [Логика обработки]
└── [Результат]
... и так далее до завершения
```
**B. ТАБЛИЦА СЕРВИСОВ И ОТВЕТСТВЕННОСТЕЙ:**
| # | Сервис/Пакет | Метод | Бизнес-ответственность | Техническая ответственность | Вход → Выход |
|---|--------------|-------|------------------------|-----------------------------|--------------|
| 1 | `[путь]` | `[метод]` | [Что делает для бизнеса] | [Как делает технически] | `[типы входа]` → `[типы выхода]` |
**C. КЛЮЧЕВЫЕ СТРУКТУРЫ ДАННЫХ И ИХ ЖИЗНЕННЫЙ ЦИКЛ:**
```
Структура: [Имя структуры]
- Где создается: [пакет/файл]
- Как заполняется: [методы]
- Где используется: [список мест]
- Когда уничтожается: [конец процесса/сохранение]
```
**D. ОБРАБОТКА ОШИБОК И ГРАНИЧНЫХ СЛУЧАЕВ:**
- Какие ошибки обрабатываются явно?
- Что происходит при падении внешнего сервиса?
- Как обрабатываются пустые данные?
- Есть ли retry-логика?
### **ШАГ 4: АРХИТЕКТУРНЫЕ ВЫВОДЫ И РЕКОМЕНДАЦИИ**
1. **Точки расширения:** Где проще всего добавить новую логику?
2. **Точки изменения:** Если нужно поменять X, идти в Y
3. **Потенциальные проблемы:** Где могут быть узкие места?
4. **Тестовое покрытие:** Какие сценарии критично покрыть тестами?
---
### **КРИТИЧЕСКИЕ ВОПРОСЫ ДЛЯ АНАЛИЗА КОДА:**
Когда смотришь на код, задавай себе:
1. **"Почему?"** — Почему эта проверка здесь? Почему именно такой алгоритм сравнения?
2. **"Что если?"** — Что если данных будет в 100 раз больше? Что если внешний сервис не ответит?
3. **"Где еще?"** — Где еще в коде используется эта логика? Есть ли дублирование?
4. **"Как узнать?"** — Как система узнает, что процесс завершился успешно?
### **ПРИМЕР ТОГО, ЧТО Я ОЖИДАЮ В ОТВЕТЕ:**
```markdown
## БИЗНЕС-СЦЕНАРИЙ
1. **Пользователь:** Cron-задание, которое запускается каждый час
2. **Проблема:** Скидки пользователей устаревают, нужно синхронизировать с системой лояльности
3. **Объекты:**
- Пользователь: имеет текущую скидку и сегмент
- Скидка: процент, который меняется при изменении статуса лояльности
- Сегмент: группа пользователей с одинаковой скидкой
4. **Бизнес-правила:**
- Правило 1: Обновлять только если изменилась скидка (compare_dealer_programs.go:89)
- Правило 2: Пользователи без скидки в DWH удаляются из всех сегментов (comparator.go:112)
## ТАБЛИЦА СЕРВИСОВ
| # | Сервис | Метод | Бизнес-ответственность | Техническая ответственность | Вход → Выход |
|---|--------|-------|------------------------|-----------------------------|--------------|
| 1 | `update_runner` | `Handle()` | Оркестрация процесса синхронизации | Маршрутизация вызовов, обработка ошибок | `RunDataUpdaterIn` → `error` |
| 2 | `clients/dwh` | `ExportDealerLoyaltyProgram()` | Получение актуальных статусов лояльности | HTTP-запрос к DWH, парсинг ответа | `context` → `[]DealerLoyaltyProgram` |
```
---
## **ДОПОЛНИТЕЛЬНЫЕ ИНСТРУКЦИИ ДЛЯ LLM:**
```
ВАЖНО: Не просто пересказывай код построчно. Анализируй:
1. СНАЧАЛА ПОНЯТЬ:
- Какие комментарии в коде? Они могут раскрывать бизнес-логику
- Имена переменных: `userDiscount`, `segmentID`, `loyaltyTier`
- Названия методов: `compare`, `sync`, `update`, `notify`
2. ЗАТЕМ СТРУКТУРИРОВАТЬ:
- Группируй связанные методы
- Выделяй паттерны (паттерн Компаратор, паттерн Репозиторий)
- Определяй слои (transport, service, repository, client)
3. НАКОНЕЦ, ОБЪЯСНИТЬ:
- Если бы ты был новым разработчиком, что бы тебе показали в первую очередь?
- Где "живет" основная бизнес-логика?
- Какие файлы меняются чаще всего?
```
