ADR-006: Замечания verify BR 1.5 — Store Service контракты
Контекст
При верификации BR 1.5 (управление ТТ) обнаружены расхождения между слоями документации. Фиксируем решения.
Замечание 1: NAME_DUPLICATE отсутствует в API.md
Проблема
Фронт-спека (09-Frontend Specs/Админка Франшизы/Торговые точки — Карточка.md, строка 119) описывает серверную ошибку NAME_DUPLICATE — дубликат названия ТТ в рамках одного ЮЛ.
В API.md (03-Services/Store Service/API.md) эндпоинты POST /stores и PATCH /stores/{id} не содержат этот код ошибки.
Решение
Добавить NAME_DUPLICATE (HTTP 409) в ошибки POST /stores и PATCH /stores/{id}:
| Code | HTTP | Когда |
|---|---|---|
NAME_DUPLICATE | 409 | ТТ с таким названием уже существует в рамках данного ЮЛ |
Уникальность: UNIQUE(legal_entity_id, name) среди неудалённых записей (deleted_at IS NULL).
Замечание 2: GET /stores (список) — сокращённый response
Проблема
GET /stores возвращает сокращённый объект (без latitude, longitude, email). Фронт-спека списка не использует эти поля → не расхождение.
Решение
Оставить как есть. Список не требует координат и email — это экономит трафик. Полные данные доступны через GET /stores/{id}.
Замечание 3: Events.md пустой
Проблема
Events.md не содержит событий. Side-эффект “приостановка ЮЛ → ТТ suspended” реализуется через internal API (POST /internal/stores/unpublish-by-legal-entity), а не через Kafka-события.
Решение
На MVP это корректно — User Service вызывает Store Service напрямую через internal API при приостановке ЮЛ. Kafka-события для Store Service (e.g. store.published, store.created) будут добавлены в Phase 2, когда появятся потребители (Customer BFF, Order Service).
Добавить пометку в Events.md с объяснением.
Действия
- Зафиксировать решения в ADR
- Добавить
NAME_DUPLICATEв API.md (POST /stores, PATCH /stores/{id}) - Добавить пометку в Events.md про internal API vs events
- Добавить UNIQUE индекс в Data Model.md
- Добавить проверку в код (StoreService + StoreRepository + миграция 004)