Пожарная каланча, колокол и Event-Driven Architecture В XVIII веке в каждом крупном городе стояла пожарная каланча. На самом верху сидел наблюдатель и смотрел на город. Заметил дым -> бьёт в колокол. Он не бежит тушить пожар. Не вызывает скорую. Не оцепляет улицу. Он просто сообщает: "Пожар в восточной части города". Дальше каждая служба сама решает, что делать. Пожарные едут тушить. Полиция оцепляет квартал. Скорая готовится принимать пострадавших. Водовозы подвозят воду. Наблюдатель не знает, кто его слушает. Службы не знают друг о друге. Единственное, что их связывает - колокол. Это Event-Driven Architecture. Буквально. Представьте платёжную систему, в которой несколько продуктов. У каждого свой процессинг, своя база пользователей, свои тарифы. Классический подход: платёжный сервис получает webhook от платёжной системы и напрямую вызывает нужный сервис. Знает кого вызвать, знает формат, знает контракт. Связанность максимальная. Event-Driven подход: платёжный сервис получает webhook и кладёт событие в очередь. Всё. Он не знает, кто это событие прочитает. Дальше, цепочка независимых сервисов. Каждый слушает очередь. Один знает всё о тарифах первого продукта и работает с его базой пользователей. Другой обслуживает второй продукт. Третий отправляет уведомления. Четвёртый управляет рекуррентными платежами. Ни один сервис не знает о существовании другого. Как пожарные не знают, что скорая тоже выехала. Их связывает только очередь событий. Когда появляется третий продукт - не нужно трогать существующие сервисы. Просто новый сервис подписывается на события из очереди. Остальные об этом даже не узнают. Кстати, если проводить аналогию с принципами ТРИЗ, то это называется принцип "Посредника". Ввести промежуточный объект, который передаёт действие. Колокол на каланче. Брокер сообщений в микросервисах. Одна и та же идея - с разницей в 250 лет. Telegram