Комментарии 5
То, что Вы тут описываете как Решение (именно так, с большой буквы РРы :)) "современных" проблем, на самом деле описано Фаулером в статье Event Sourcing 15 лет назад. И за эти годы накопилось достаточно опыта, чтобы понять, что для абсолютного большинства проектов это решение создаёт намного больше проблем, чем решает. Для бизнеса Event Sourcing это дорого, сложно и обычно не нужно. См. например Почему Event Sourcing — это антипаттерн для взаимодействия микросервисов. Без событий современные проекты действительно редко обходятся, но вот использование их в стиле Event Sourcing — должно быть очень хорошо продуманным решением, и уж точно не первым вариантом используемым по умолчанию на большинстве проектов.
Кстати статья про антипаттерн именно про то, что не стоит смешивать события, которые вы используете для хранения состяния(ES), с событиями, которые вы используете для взаимодействия компонет системы(EDA).
Брокер сообщений выглядит как узкое место системы. Если генераторов и потребителей событий может быть сколько угодно и их можно масштабировать, то общаются они все через одного брокера. Мало того, брокер может и упасть, что приведёт к полной остановке системы.
Или есть варианты с пулом брокеров?
Как событийно-ориентированная архитектура решает проблемы современных веб-приложений