Comments 5

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

Event Sourcing и EDA — это разные вещи. EDA появилась задолго до Event Sourcing. Но в статье вроде и не утверждается, что EDA это что-то новое. Там говорится лишь, что EDA решат современные проблемы.

Кстати статья про антипаттерн именно про то, что не стоит смешивать события, которые вы используете для хранения состяния(ES), с событиями, которые вы используете для взаимодействия компонет системы(EDA).

Брокер сообщений выглядит как узкое место системы. Если генераторов и потребителей событий может быть сколько угодно и их можно масштабировать, то общаются они все через одного брокера. Мало того, брокер может и упасть, что приведёт к полной остановке системы.
Или есть варианты с пулом брокеров?

Да и на это есть ответ. Класс distributed broker с их самым известным представителем apache kafka

Мне кажется кафка достаточно масштабируемая и отказоустойчивая для таких случаев.
Only those users with full accounts are able to leave comments. Log in, please.

Information

Founded
Location
Россия
Website
piter.com
Employees
201–500 employees
Registered