Перейти к содержанию

user_service

1. Назначение

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

2. API-каталог

Базовый префикс: /api/.

Метод Путь Auth Назначение
GET /health/ AllowAny Health-check
GET /ops/ttm/ AllowAny Серверные TTM-маркеры
POST /ops/ttm/mark/ AllowAny Запись TTM-маркера (CI/CD)
GET/POST /profiles/ IsAuthenticated Список/создание профилей
GET/PUT/PATCH/DELETE /profiles/{id}/ IsAuthenticated Работа с профилем
GET /profiles/me/ IsAuthenticated Профиль текущего пользователя
GET /profiles/sellers/ IsAuthenticated Профили продавцов
GET /profiles/buyers/ IsAuthenticated Профили покупателей
POST /profiles/request_seller_status/ IsAuthenticated Заявка на статус продавца
GET /sellers/, /sellers/{id}/ AllowAny Публичные seller-профили
GET /buyers/, /buyers/{id}/ IsAuthenticated Buyer-профили с ограничениями

3. Модель данных

UserProfile

  • user OneToOne -> auth_app.User
  • role: seller|buyer|both
  • phone, bio, avatar, address
  • timestamps

SellerProfile

  • user_profile OneToOne -> UserProfile
  • shop_name, rating, total_sales, verified

BuyerProfile

  • user_profile OneToOne -> UserProfile
  • total_orders, total_spent

SellerStatusRequest

  • user FK -> auth_app.User
  • status (фактически используется pending)
  • requested_at

4. Бизнес-правила

  • Non-staff пользователь видит только свой профиль/покупательские записи.
  • request_seller_status запрещен, если:
  • пользователь уже seller|both;
  • существует pending-заявка.
  • Для me профиль создается автоматически (get_or_create).

5. Валидации и edge-cases

  • Роль ограничена choices.
  • Возможен риск в POST /profiles/ из-за обязательного поля user в модели при отсутствии его в serializer fields.
  • Нет атомарной защиты от гонок для создания повторных pending-заявок.

6. Конфигурация и запуск

  • Внешний порт по Compose: 8002.
  • Основные env: DATABASE_URL, SECRET_KEY, DEBUG, fallback DB_*.
  • Важная зависимость: доступность auth_service app для AUTH_USER_MODEL.

7. Диаграмма workflow seller-заявки

stateDiagram-v2
  [*] --> buyerRole
  buyerRole --> pendingRequest: request_seller_status
  pendingRequest --> approved: moderation_approve
  pendingRequest --> rejected: moderation_reject
  approved --> sellerRole
  rejected --> buyerRole

8. Риски

  • Ролевая модель может быть изменена через update endpoint без отдельного процесса модерации.
  • Security defaults в settings небезопасны для production (DEBUG, ALLOWED_HOSTS).

9. Дополнительная детализация внутренних функций (append-only)

9.1 UserProfileViewSet.get_queryset(self)

  • Источник: user_service/user_app/views.py
  • Назначение: role-based ограничение выборки профилей.
  • Вход:
  • request.user.
  • Выход:
  • для staff: все UserProfile;
  • для обычного пользователя: только профиль текущего пользователя.
  • Side effects:
  • отсутствуют (read-only selection logic).

9.2 UserProfileViewSet.me(self, request)

  • Источник: user_service/user_app/views.py
  • Назначение: endpoint "мой профиль".
  • Вход:
  • текущий аутентифицированный пользователь.
  • Выход:
  • профиль пользователя в формате UserProfileSerializer.
  • Side effects:
  • get_or_create: при первом вызове может быть создана запись UserProfile.

9.3 UserProfileViewSet.sellers(self, request) и buyers(self, request)

  • Источник: user_service/user_app/views.py
  • Назначение: фильтрация профилей по роли.
  • Вход:
  • query без обязательных параметров.
  • Выход:
  • коллекция профилей:
    • sellers: роли seller и both;
    • buyers: роли buyer и both.
  • Edge-cases:
  • логика зависит от поля role, а не от физического наличия связанных SellerProfile/BuyerProfile.

9.4 UserProfileViewSet.request_seller_status(self, request)

  • Источник: user_service/user_app/views.py
  • Назначение: создать заявку на повышение роли до продавца.
  • Вход:
  • аутентифицированный пользователь.
  • Выход:
  • 200 при создании заявки;
  • 400, если пользователь уже seller|both или уже есть pending-заявка.
  • Side effects:
  • создание SellerStatusRequest.
  • Edge-cases:
  • без транзакционной защиты возможна гонка при параллельных запросах.

9.5 BuyerProfileViewSet.get_queryset(self)

  • Источник: user_service/user_app/views.py
  • Назначение: ограничить доступ к buyer-профилям.
  • Вход:
  • request.user.
  • Выход:
  • staff: все buyer-профили;
  • non-staff: только buyer-профиль, связанный с его UserProfile;
  • если профиль пользователя отсутствует: пустой queryset.

9.6 Контракты данных для внутренних функций

  • UserProfileSerializer: базовый профиль и его редактируемые поля.
  • SellerProfileSerializer: публичные/операционные поля продавца.
  • BuyerProfileSerializer: агрегаты по покупателю (total_orders, total_spent).
  • SellerStatusRequest:
  • жизненный цикл в коде ориентирован на pending, дальнейшая модерация выполняется внешним админ-контуром.

10. Соответствие master-документации

Источник верхнего уровня: Master-документация проекта.

Контроль Требование Проверка Артефакт
Role lifecycle Переходы ролей и seller request flow задокументированы проверка state transition сценариев QA + docs
Access control Доступ к buyer/seller профилям строго ограничен permission проверки queryset/action integration tests
Contract sync Изменения user-полей синхронизированы с frontend/admin cross-service контрактный ревью PR checklist
Risk governance Ограничения профилей и модерации отражены в рисках ревью риск-секций governance docs