---

[I128-2794] Реализовать системную событийную шину EventBus

---

НАЧАЛО >> Оглавление >> Общее описание >> История изменений >> Что нового в проекте I128 >> Версия 2026.3 >> [I128-2794] Реализовать системную событийную шину EventBus📄 Скачать в DOCX

---

Тип	Версия	Статус	Приоритет	Исполнитель
⚙️ Новые возможности	2026.3	🔘 Завершено	Средний	Ilya Mikhaylenko

Компоненты: Нет

Завершено: 08.09.2026 12:51

1. Цель Реализовать системную событийную шину EventBus для ИРБИС 128: единый механизм фиксации событий, transactional outbox, inbox, подписок, доставок, повторов, dead-letter, идемпотентности и диагностики событийных операций.

2. Контекст EventBus является новым системным runtimeмодулем. Его не нужно смешивать с существующим предметным модулем мероприятий Event. EventBus не знает структуру задач, обращений или других доменных записей: модуливладельцы публикуют события и предоставляют schemas, payload profiles, handlers и resolvers.

3. Что Нужно Сделать

• Ввести модель EventType: ключ события, владелец, версия schema, класс выполнения, retention, masking policy и правила совместимости версий.

• Ввести модель EventRecord: event id, type, version, source module, object reference, actor, occurred at, trace id, idempotency key, payload, payload profile и технический статус обработки.

• Реализовать publication API для синхронной фиксации критичных событий вместе с доменным действием через transactional outbox.

• Реализовать outbox/inbox: событие не должно теряться при сбое доставки, повторе запроса или перезапуске worker-а.

• Реализовать subscriptions: модуль или транспорт может подписаться на событие по типу, владельцу, object reference, scope и policy.

• Реализовать delivery attempts: статус, время, канал, handler, результат, ошибка, next retry, количество попыток, trace id.

• Реализовать retry/backoff и deadletter для событийных доставок. Deadletter должен быть видимым, диагностируемым и поддерживать безопасный ручной повтор.

• Реализовать idempotency registry для защиты от повторов UI/API/webhook/Queue и повторной доставки одного и того же события.

• Реализовать payload masking: секреты, персональные данные и скрытые поля не должны попадать в публичный вывод, логи и диагностические отчеты.

• Реализовать интеграцию с Queue для тяжелых обработчиков, с TraceContext для диагностики, с Security для прав просмотра и с HealthCheck для проверки готовности конфигурации.

• Предусмотреть providerконтракт для модулейвладельцев: регистрация типов событий, schemas, handlers, payload profiles, validation и TestA fixtures.

  1. Границы Ответственности

• EventBus хранит факт события и управляет доставкой, но не выполняет доменную бизнеслогику за модульвладелец.

• EventBus не является очередью произвольных задач: тяжелое выполнение должно идти через Queue.

• EventBus не заменяет стандартную историю действий 907 и не является пользовательской лентой; такие представления строятся отдельными потребителями.

  1. Критерии Приемки

• Критичное событие изменения состояния надежно фиксируется вместе с доменным действием или действие считается незавершенным.

• Необязательная доставка не откатывает уже сохраненную запись, а уходит в retry или dead-letter.

• Повтор одного и того же внешнего или пользовательского действия не создает дубликаты событий.

• Администратор видит состояние outbox, inbox, delivery attempts и dead-letter с безопасной диагностикой.

• Модуль-владелец может добавить новый тип события без изменения ядра EventBus.

  1. Проверки И Документация Нужно подготовить TestAсценарии для publication, transactional outbox, inbox, subscription, delivery, retry, deadletter, idempotency conflict, masking, HealthCheck provider и trace propagation. В Help должны быть описаны настройка типов событий, подписок, доставок, recovery и разработка handlers.

-

Первый кодовый срез системной событийной шины EventBus.

Сделано:

• добавлен модуль EventBus с DTO EventBusEvent и EventBusSubscription;
• добавлен реестр типов событий и подписок;
• добавлена публикация событий с idempotency key и конфликтом fingerprint;
• добавлен dryrun план доставки, deadletter и срез событий по trace id;
• добавлена provider-проверка HealthCheck_Self без зависимости от модуля HealthCheck;
• добавлены system JSON определения, Help и TestA safe-read.

Границы: EventBus не содержит доменную логику Tasks/Workflow, не заменяет Queue и транспортные модули.

Проверка: TestA EventBus safe-read: total=8, passed=8, failed=0.

1. Связанные задачи

1.1. 🔗 blocks: I128-2803

1.2. 🔗 blocks: I128-2805

1.3. 🔗 blocks: I128-2806

1.4. 🔗 blocks: I128-2807

1.5. 🔗 blocks: I128-2808

1.6. 🔗 blocks: I128-2809

1.7. 🔗 blocks: I128-2810

1.8. 🔗 blocks: I128-2811

1.9. 🔗 blocks: I128-2818

1.10. 🔗 blocks: I128-2820

1.11. 🔗 blocks: I128-2821

1.12. 🔗 blocks: I128-2822

1.13. 🔗 blocks: I128-2824

1.14. 🔗 blocks: I128-2827

1.15. 🔗 blocks: I128-2830

1.16. 🔗 blocks: I128-2832

1.17. 🔗 blocks: I128-2838

1.18. 🔗 blocks: I128-2839

1.19. 🔗 blocks: I128-2840

1.20. 🔗 blocks: I128-2793

1.21. 🔗 relates to: I128-2792