Декомпозиция BR 2.5 — Статусная модель заказа Фаза 1
Источник
Затронутые сервисы / репозитории
| Сервис | Порт | Репо | Задачи |
|---|---|---|---|
| Catalog Service | :3004 | erp-catalog-service | Catalog Service |
| Order Service | :3005 | erp-order-service | Order Service |
| Aggregator Service | :3013 | erp-aggregator-service | Aggregator Service |
| Admin BFF | :3020 | erp-admin (bff/) | Admin BFF |
| Admin Franchise web | :3020 | erp-admin (web/) | Admin Franchise |
| Warehouse Service | :3008 | erp-warehouse-service | — возможные правки (открытый вопрос §10.1 BR) |
POS (наш и KOALa) — не трогаем (user-directive).
Последовательность выполнения
- Catalog Service — добавить таблицу
kitchen_stations+ поля вproducts. API для stations. Развёртывается первым, т.к. Order Service на checkout’е будет читатьrequires_kitchenиз товара. - Order Service — state-machine + новые endpoints + новые события. Зависит от Catalog Service для расчёта
orders.requires_kitchen. - Aggregator Service —
webhook_subscriptionsтаблица + webhook dispatcher. Подписчик Kafka-событий Order Service. Может деплоиться параллельно с Order Service. - Admin BFF + Admin Franchise web — проксирование новых endpoints + UI для kitchen_stations, бейджи новых статусов. Зависит от Catalog + Order.
Риски / открытые вопросы на реализацию
См. BR 2.5 §10. Критично решить до начала:
- Warehouse списание — на
order.paidилиorder.closed? (Открытый вопрос, требует согласования с Warehouse разработкой) /checkoutendpoint — ломать (возвращать 409 для dine-in/delivery) или сохранять обратную совместимость (внутренне делать pay+close)? Решение: сохраняем обратную совместимость — если старый клиент зовёт/checkoutнаdine_in, внутренне делаемpay+closeсразу. Логируем deprecation.- Retry-политика webhook (10s..24h) — как дефолт, после первых недель можно корректировать
Прогресс
- Catalog Service — миграция 025 +
kitchen_stationsCRUD + поляrequires_kitchen/kitchen_station_id+GET /internal/products/require-kitchen - Order Service — миграция 008 (расширение CHECK-constraint + 8 новых колонок) + state machine BR 2.5 + transitions (
start-delivery,confirm-delivery) + события (order.closed,order.cooking_started,order.ready,order.handed_over,order.in_delivery,order.delivered) +CatalogServiceClientдляrequires_kitchenна checkout - Aggregator Service — миграция 002 +
webhook_subscriptions+webhook_delivery_attempts+HmacSigner+WebhookSubscriptionService(CRUD, secret MVP plaintext) +WebhookDispatcher(Kafka-подписчик на order.*) +WebhookDeliveryWorker(scheduled retry с backoff[10s, 30s, 2m, 10m, 1h, 6h, 24h], max_attempts=7) + internal controllers (CRUD + retry manual) - Admin BFF — прокси для
/kitchen-stationsCRUD,/orders/:id/{accept,ready,hand-over,start-delivery,confirm-delivery,complete,cancel}; обновлены shared types (OrderStatus+in_delivery/delivered,Order+ 8 timestamps,KitchenStation,Product.requires_kitchen/kitchen_station_id) - Admin Franchise web —
KitchenStationsPage(CRUD-список + модалки) + меню в Layout, секция «Кухонный flow» вProductCreatePage/ProductEditPage(toggle + select station), бейджиin_delivery/deliveredвActiveOrdersPage/OrderHistoryPage/OrderDetailPage