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

Я создаю логин и аутентификацию пользователя в 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 для чтения, поэтому я могу думать, что это может быть правильно.

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

domain-driven-design,cqrs,event-sourcing,axon,

0

Ответов: 1


3 принят

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

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

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

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

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

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

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

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

домен привод дизайн, CQRS, событийно-источники, аксон,
Похожие вопросы
Яндекс.Метрика