Mediator — центр управления взаимодействием между компонентами

Mediator устраняет прямые связи между компонентами системы, передавая все взаимодействие через единый посредник. Это позволяет снизить связанность, упростить коммуникацию и сделать архитектуру управляемой и расширяемой.

Паттерн особенно полезен, когда множество объектов должны согласованно взаимодействовать друг с другом, но прямые связи создают избыточную сложность и трудности с изменениями.

Mediator применяется в интерфейсах, интеграциях, workflow-системах, взаимодействии доменных сервисов, в микросервисах и в архитектуре событий.

Mediator — один из важнейших паттернов, когда архитектор хочет управлять взаимодействием между объектами, сервисами или подсистемами. Изначально он задуман для ООП, но в архитектуре ИС используется шире: в микросервисах, интеграциях, EDA, UI-фреймворках, BPM-системах, оркестрации процессов.

Главная идея паттерна

Mediator вводит центральный объект — посредник, который принимает сообщения от компонентов и решает, кому их направить.
Компоненты НЕ знают друг о друге, они знают только медиатора.

Это устраняет паутину связей и делает систему модульной.

Типичные проблемы, которые решает Mediator

1. Слишком много прямых зависимостей
   Компонент A вызывает B, B вызывает C, C вызывает A — зависимость растет нелинейно.

2. Сложно менять процессы
   Изменение последовательности действий требует правок во всех компонентах.

3. Ограниченная повторная используемость
   Компоненты слишком зависят от окружения.

4. Трудности тестирования
   Нужно поднимать всю систему целиком, чтобы протестировать одну часть.

Mediator устраняет всё это за счёт централизованного управления коммуникациями.

Где используется Mediator в реальных системах

1. UI и Desktop-приложения
   Графические компоненты не должны знать друг о друге.
   Windows Forms, Swing, Qt — используют Mediator глубоко внутри.

2. Интеграционные решения и SOA
   Здесь Mediator проявляется как ESB (Enterprise Service Bus) или Integration Hub.
   А также в брокерах сообщений, когда они координируют обработку.

3. Оркестрация процессов
   В BPM и Orchestration Mediator — это движок процессов, управляющий шагами.

4. Микросервисы
   Сервис-оркестратор (например, Saga orchestrator) — классический Mediator.

5. DDD и доменные события
   Domain Event Handlers часто выполняют роль медиаторов:
   — получили событие,
   — определили, что нужно вызвать,
   — распределили работу по сервисам.

6. Workflow и pipelines
   Например, обработка документов, расчёт тарифов, обработка заявок.

Преимущества Mediator

• Снижение связанности — компоненты независимы друг от друга.

• Управляемая коммуникация — логика взаимодействий централизована.

• Легко менять процессы — достаточно переписать медиатор.

• Упрощение тестирования — можно мокать медиатор.

• Повышение расширяемости — добавление новых участников не ломает существующую систему.

Недостатки

• Mediator может перерасти в «бога» логики.

• Требуются строгие архитектурные правила.

• Неправильная реализация приводит к перегруженному центру.

Однако грамотный архитектор избегает этих проблем за счёт декомпозиции медиаторов и использования цепочек событий.

Mediators в современных архитектурах

В архитектуре ИС mediator соответствует конкретным элементам:

• Saga orchestrator управляет шагами цепочек операций.

• Workflow engines управляют состояниями.

• Integration Bus маршрутизирует сообщения.

• API Gateway маршрутизирует запросы между сервисами.

• Event Router распределяет события по подписчикам.

Таким образом, Mediator — это универсальный инструмент управления сложностью.

Почему архитектор должен владеть Mediator

На рынке труда это один из обязательных навыков.
Все крупные системы используют Mediator в той или иной форме.

Архитектор должен уметь:
— выявлять избыточную связанность;
— вводить централизованное взаимодействие;
— управлять процессами через оркестрацию;
— обеспечивать слабую связанность между подсистемами;
— понимать, когда Mediator лучше заменить Event-driven подходом.