ADR 0007: Сигналы, слабая связность и снятие нагрузки с UI¶
Статус: Accepted (внедрение — strangler)
Дата: 2026-04-02
Связанные ADR¶
| ADR | Роль |
|---|---|
| 0004 | Маршалинг обновлений UI через IUiScheduler |
Вне ADR¶
| Документ | Роль |
|---|---|
| architecture-migration.md | фаза 5 |
Контекст¶
В IDE много источников и потребителей сигналов (сборка, диагностики, MCP, LSP и т.д.). Без правил растёт связность, хаотичные вызовы между подсистемами и ошибки потоков. Большие потоки текста могут перегружать привязки UI.
Решение¶
Внедрять поэтапно (strangler), без обязательной смены всего кода сразу:
-
Границы и уведомления — источники по возможности только публикуют факты (событие, узкая шина, узкий контракт); потребители не тянут друг друга напрямую там, где достаточно реакции на факт. Конкретная механика (event bus, IObservable, медиатор) — по месту. Цель: слабая связность и предсказуемый граф зависимостей.
-
Маршалинг на UI-поток — см. ADR 0004 (
IUiScheduler/UiScheduler.Default), без размазанного Post/Invoke по коду. -
Очереди и батчинг (точечно) — где поток данных перегружает UI (длинный вывод сборки, лавина диагностик): канал или очередь и пакетное обновление VM, чтобы не дергать привязки на каждую строку.
Паттерны: listener/pub-sub для топологии много ко многим; producer/consumer для участков с нагрузкой; dispatcher-слой в первую очередь для маршалинга на UI-поток и при необходимости маршрутизации команд, а не замены DI.
Последствия¶
Статус по шагам ведётся в architecture-migration.md.
Отклонённые альтернативы¶
- Вводить тяжёлый глобальный event bus на весь продукт сразу — отклонено в пользу точечных решений и strangler-миграции.