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-миграции.