CQRS / ES - логин пользователя со стороны чтения или записи

Question

Я создаю логин и аутентификацию пользователя в CQRS с источником событий (с AXON Framework)

Follwing - это шаги в моей модели -

1. Поток регистрации пользователей -

   UserRegistrationCommand handles the user registration , since the 
   application makes the uniqueness between users using email , means only one 
   user can register with one email. (For this I was maintaining the table on 
   read side , which contains the registered email address. So when user tries 
   to register ,We query the read side for the validation of email address 
   from client side (not from the write side),and show a message "This email 
   is already register").
   
   When the client validation passes ,the UserRegistrationCommand is issued and 
   handled by the command handler , which then fires an event called 
   UserRegistredEvent , and this event is handled by the event handler on read 
   side and updates the read side DB.
   

   2. UserLogin Flow - Я немного запутался по поводу UserLogin.

   У меня в уме два подхода:

   Первый подход -

   User login using the read side, means user enters the username and 
   password. And this username and password is validated from read side, and   
   UserLogedInEvent is fired from the read side and catched by the write side and is
   saved in event store.
   

Но я никогда не видел ни одной диаграммы архитектуры, которая бы читала побочные эффекты и события и обрабатывала их на стороне записи.

Так я могу это сделать?

Второй подход -

 User login using write side , means the user issues UserLogingCommand 
 and before the command dispatch to command handler , we validate the 
 username and password using the read side by accessing the same public api 
 of read side (which was used in first approach). 

Но проблема в том, что мы не можем использовать сторону чтения на стороне записи (как я читал и знать в архитектуре cqrs). Но так как я использую публичный API стороны чтения, я могу подумать, что правильный.

Так какой подход вы, ребята, предлагаете, ИЛИ есть какой-то другой подход, чтобы сделать это

Answer 1

мы не можем использовать сторону чтения на стороне записи (как я читаю и знаю в архитектуре cqrs)

Это не совсем верно. Нет ничего плохого в использовании данных на стороне чтения при вычислении записи - вам просто нужно знать о задержке .

Я никогда не видел ни одной диаграммы архитектуры, которая считывала бы побочные события и события и обрабатывала бы стороной записи

Это достаточно распространенный шаблон: подписчик следит за изменениями в моделях чтения и вычисляет команды для отправки для записи моделей. Если вы ищете «диспетчер процессов» и «управляемая событиями архитектура», вы можете найти диаграммы, которые вы ищете.

Например, Алиса размещает заказ. Поэтому мы записываем это в книгу заказов и, как следствие, отправляем сообщения в службу выставления счетов и службу исполнения.

Так какой подход вы, ребята, предлагаете

Честно? Купите товарное решение для входа в систему и аутентификации и перейдите к проблеме, которая имеет значение для основного бизнеса.

Но если вы катитесь самостоятельно, я думаю, что вам нужно внимательно посмотреть, каковы ваши требования к задержке, и работать оттуда.