Comments 4
Спасибо за статью. Вопрос (без подкола, т.к. самому интересно): разве это правильный подход хранить в event store такие данные как, например, password? Ведь у вас какждый раз при регистрации происходит отправление команды:
@CommandHandler
public UserAggregate(SignupUserCommand command) { apply(new UserSignedUpEvent(command.getUserId(), command.getUsername(), command.getPassword(), command.getEmail()));}
Мои личные размышления насчёт работы с cqrs и saga сводятся к тому, что их можно использовать в некоторых экзотических случаях, связанных с :
а) Необходимостью быстрого чтения данных (т.к. у нас существует отдельная база для query-запросов)
б) Межмикросервисные транзакции но это спорный вопрос, насколько вообще правильно в ущерб соблюдения консистентности данных делать такие вещи через цепочку command-event а потом, в случае ошибки, делать такую же цепочку компенсационных транзакций.
Xранение пароля в event-store, с точки зрения безопасности, ничем не отличается от его хранения в любой другой базе. Разумеется, так же как и в других случаях, пароли следует хранить в кодированном виде (bcrypt и т.п.), плюс никто не отменял SSL и прочих предосторожностей. Axon server располагает приличным арсеналом средств безопасности. Подробнее можно посмотреть здесь: https://docs.axoniq.io/reference-guide/axon-server/security
А что произойдёт, если логика "откат создания пользователя" не отработает?
Здесь работает модель согласованности в конечном счете (eventually consistency), которую я упоминал, когда описывал кейс. Даже если сервис, выполняющий откат, недоступен в момент отправки команды отката, событие отката будет в очереди Axon, пока не будет обработано. Как только обработчик будет доступен, событие будет обработано и данные станут консистентными. Это распространенный подход в микросервисной разработке.
Saga и Event Sourcing с Axon. Первое знакомство