Comments 10
Вместо нее используется так называемая In-Memory Bus, что позволяет обрабатывать команду и события в одной транзакции и в случае неудачи откатить все целиком.
На картинке «In-Memory Bus» перечеркнуто… Непонятно, как это интерпретировать.
Было бы также интересно узнать требования по производительности (RPS) и какое «железо» под это выделяется.
Требований по производительности формализованных нет. Заказчик маленький, команда маленькая, весь проект делается немного «на коленке».
Про железо. Сейчас все компоненты живут в одном App Service Plan в Azure и этого хватает. App Service Plan автоматически скейлится горизонтально, плюс перед/после аукционами (на данном этапе развития платформы известно, когда кто из пользователей платформы проводит аукционы) скейлится вверх/вниз.
Если говорить о том, каких нагрузок мы ожидаем в течение, например, ближайшего года, то это, если говорить о командах CQRS, десятки команд в секунду, вряд ли сотни.
Вообще-то непонятно, почему было принято архитектурное решение CQRS/ES. Логики не прослеживается именно в описании выбора. Дано:
1) пришел готовый проект, который писали по CRUD.
2) Он работает плохо. Симптоматика кратко дана.
3) ?????
4) Поэтому решили делать на CQRS/ES.
Почему плохо подходит CRUD? Может, это проблема реализации, а не подхода? Как CQRS/ES была признана способной решить именно эти проблемы, помимо "поговорили с коллегами"? Что получилось сделать хорошо, помимо описанных в статье проблем? Это хорошо, что тут CQRS/ES подошел отлично, исходя из опыта проекта, но из статьи совсем не понятно, почему.
Ну и в самом CQRS сливать Event и Command в одной транзакции — это достаточно сильное искажение архитектуры. Command может быть проигнорирован, а Event обязан выполниться — это их основное отличие, диктующее способ применения.
Ну и в самом CQRS сливать Event и Command в одной транзакции — это достаточно сильное искажение архитектуры. Command может быть проигнорирован, а Event обязан выполниться
Идеологически — да. Технически, event обязан выполниться, если он сохранен в write-базу. Но я согласен, что реализация с транзакцией — это скорее костыль, чем то, чем можно было бы похвастаться. Есть желание переписать всю техническую реализацию заново, с учетом полученного опыта. Но нет ресурса. Пока нет.
Если вам нужно реактивное взаимодействие с объектами в реальном времени, стоит посмотреть в сторону акторов. Например, Orleans или akka.net. Рассматривали этот вариант?
Применение CQRS & Event Sourcing в создании платформы для проведения онлайн-аукционов