Как стать автором
Обновить

Комментарии 8

Спасибо за доклад!


Почему Rebus, а не тот же MassTransit?

Rebus уже работал на одном крупном и нагруженном корпоративном проекте и показал себя хорошо. Там он появился как частичная замена SQL Server Service Broker в качестве очередей сообщений, т.к. SSSB не справлялся с нагрузкой. Тогда трудно было понять, что лучше – всё только появлялось, ну и Rebus как-то проще показался + неплохо документирован. Новый проект появился немного позже и имея уже работающий на бою Rebus опять выбрали его. Сейчас есть уже другие проекты с Masstransit – но я не скажу, что это дало серьёзные преимущества или недостатки.
Что нужно помнить, работая с CQRS?


Что замучаетесь ждать выполнения команды на клиенте. Обычный REST-API помогает плохо, надо прикручивать SignalR, websocket'ы.
В общем, я бы хотел посмотреть на какое-нибудь SPA-приложение, вроде todo-list написанном на CQRS.

Ну вот да, хороший пример того, что получается сложно. Архитектура CQRS ограничивает интерфейс и приходится изголяться. Юзеру не интересно, что было до триггернутой операции, ему интересно, что будет после. А тут два выхода: websocket-ы или пинговать сервер. И всё это ради четырёх красивых буков.
CQRS не предполагает значимого замедления. Обычно оно получается когда наряду с CQRS проходит и другие значимые изменения архитектуры, типа создание реплик баз данных для запросов и появляется задержка репликации. Или внешнюю шину вводят. Или разбивают сервис на два: записи и чтения. В общем обычно когда появляется межпроцессное (часто сетевое) взаимодействие там, где его не было до введения CQRS.
Почему Rebus, а не более известный MediatR?
Если погрузиться в архитектуру, то можно увидеть что паттерн CommandProcessor описан еще в GoF, а собственно любая реализация CQRS на практике сводится к обычной обработке событий, известной уже лет 20 (пресловутые EventDispatcherThread в свинге или флеше, или любом браузерном движке). Можно еще про WAL вспомнить.

Самая главная (и единственная) проблема ES/EDA в архитектуре веб-клиентов — отсутствие server push в HTTP — всегда раньше решалась использованием протоколов более низкого уровня, а сейчас — использованием websockets. Современные веб-приложения ориентируются на Reactive Streams (на HL++ в 2017 году даже был доклад про их использование в .net), лучше стараться думать в эту сторону, а не про паттерны имени Фаулера и прочих теоретиков.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий