Нормализатор событий
Переводит provider-specific события в каноническую продуктовую модель.
Состояния на границе
Иллюстрация по теме
Визуальный ориентир помогает быстрее считать сценарий страницы и не оставлять компонент абстрактным.
Контракт компонента
| Inputs | raw provider envelope |
|---|---|
| Outputs | canonical event + mapping diagnostics |
| Failure mode | semantic loss, silent unknown mapping |
| Ownership | UI владеет представлением и recoverable context; финальное бизнес-состояние подтверждает серверный контракт. |
Решение команды
Компонент считается самостоятельной границей только если команда может назвать его входы, выходы и невозможные состояния. Если он требует читать provider-specific поля напрямую или хранит финальный статус операции только локально, граница выбрана слишком поздно.
При изменении контракта сначала обновляется state model и совместимость, затем визуальный слой. Это уменьшает риск ситуации, когда новый UI уже ожидает поле или статус, которого старая версия API не гарантирует.
Связанные разборы
Что должно пройти на приёмке
- Raw envelope сохраняется для диагностики без протекания в product API.
- Неизвестный provider status попадает в quarantine/unknown, а не тихо маппится в ближайший вариант.
- Внутренний entity id не зависит от жизненного цикла одного поставщика.
- Late/out-of-order message не откатывает каноническую версию.
- Mapping diagnostics доступны операции без изменения UI-контракта.
- Добавление нового provider проверяется контрактными fixture-тестами.
Почему нормализация заканчивается здесь
Vendor-specific семантика локализуется на ingress. Это делает смену provider и работу с несколькими источниками продуктовой задачей mapping, а не переписыванием интерфейса.
При review команда проверяет не название компонента, а его инварианты: какие данные он имеет право считать финальными, что обязан показать при деградации и как возвращается в согласованное состояние после сбоя.
Проверка на конфликтующих источниках
Дайте нормализатору два сообщения об одном событии: один provider считает матч live, второй прислал более старый pre-match status. Компонент не должен проталкивать внешнее значение напрямую в продукт. Он сохраняет raw envelope, применяет правила приоритета и оставляет достаточно диагностики для reconciliation.
Отдельный тест — неизвестный enum после обновления provider API. Безопасный результат здесь не «угадать» ближайшее значение, а вернуть controlled unknown и поднять сигнал качества фида.
Связанный маршрут: приём данных поставщика → нормализация.
Что приносить на разбор интеграции
Если normalizer остаётся «чёрным ящиком», команда слишком поздно замечает конфликт provider ids, расхождения по фазам матча или разный смысл одного и того же status flag. На review полезно приходить не только со схемой полей, но и с примерами конфликтующих payloads и правилами разрешения. Для этого случая хорошо работает связка с разбором нормализации событий от разных поставщиков.