Comments 10
Вместо нее используется так называемая In-Memory Bus, что позволяет обрабатывать команду и события в одной транзакции и в случае неудачи откатить все целиком.


На картинке «In-Memory Bus» перечеркнуто… Непонятно, как это интерпретировать.

Было бы также интересно узнать требования по производительности (RPS) и какое «железо» под это выделяется.
Это я, значит, не очень понятно изобразил. Там перечеркнуто все, что в желтом прямоугольнике.

Требований по производительности формализованных нет. Заказчик маленький, команда маленькая, весь проект делается немного «на коленке».

Про железо. Сейчас все компоненты живут в одном App Service Plan в Azure и этого хватает. App Service Plan автоматически скейлится горизонтально, плюс перед/после аукционами (на данном этапе развития платформы известно, когда кто из пользователей платформы проводит аукционы) скейлится вверх/вниз.

Я так понял, что масштабирование таки производится — но под какие требования, если не секрет? Какие характеристики, скажем, потока запросов на обновление?
Я, возможно, не вполне понимаю вопрос. Масштабирование горизонтальное производится автоматически, средствами Azure, число инстансов сервис плана изменяется на один если нагрузка на процессор переходит пороговое значение.

Если говорить о том, каких нагрузок мы ожидаем в течение, например, ближайшего года, то это, если говорить о командах 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. Рассматривали этот вариант?

Only those users with full accounts are able to leave comments. Log in, please.
Information
Founded

9 April 1993

Location

Россия

Employees

501–1,000 employees

Registered

20 January 2015

Habr blog