Куда мне поместить код для обновления токена доступа способом DDD & CQRS?

Question

Я использую ASP. NET Ядро и обучение DDD и CQRS (включая MediatR). Я прочитал eshopcontainers документы. В моем приложении нам нужно хранить токен доступа каждого пользователя и sh для Google в нашей базе данных SQL, потому что мы должны периодически проверять некоторый статус в gmail. Когда мы реализуем эту функцию, мы более или менее хотели бы написать следующую логи c.

1. Get the access token and refresh token from our DB
2. If the access token is expired, we get the valid access token with refresh token
3. If the access token is updated in step 2, we save the new access token to DB
4. With the valid access token, we fetch information from gmail

Этот процесс будет использоваться в обработчике нескольких команд в шаблоне CQRS.

Мои вопросы:

• Куда мне поместить логи c с DDD, CQRS? Должен ли он быть помещен в репозиторий, службу приложений или службу домена ...?

• Можем ли мы вызвать метод из обработчика запросов? Мне это интересно, потому что logi c иногда обновляет данные в БД, поэтому я думаю, что мы не должны вызывать этот процесс из Query Handler

Моя текущая идея - создать UserService, который включает в себя процесс, упомянутый выше. Конкретный пример моей структуры решения следующий. UserService будет использоваться в нескольких обработчиках команд и не будет использоваться в QueryHandler, поскольку он периодически обновляет БД. Однако, если есть идея получше, основанная на DDD манере, я бы хотел ее узнать.

Структура решения

Application layer (depends on Domain and Infrastructure)
 - UserController.cs
 - CommandHandlers folder (several command handlers use UserService)
 - QueryHandlers folder 

Domain Layer (No dependency)
  - UserAggregate folder
    - User.cs (Model for user)
  - IRepository.cs (Interface)

Infrastructure Layer (depends on Domain)
  - EF Core related folder
  - Repository.cs (Implemented IRepository.cs)
  - UserService.cs (has the token update process)

User.cs

public class User 
{   
    public string AccessToken { get; set; }
    public string RefreshToken { get; set; }
    public long Id {get; set;}
}

UserService.cs (просто идея)

public class UserService 
{
    ....

    GetValidAccessToken(long userId) 
    {
        var user = repository.Find(userId);
        if (user.AccessToken is expired) 
        {
            var newAccessToken = GetNewAccesstokenWithRefreshToken(user.RefreshToken);
            user.AccessToken = newAccessToken;
            repository.Save(user);
        }
        return user.AccessToken;
    }
}

Answer 1

Я согласен с @Ankit Vijay. Пожалуйста, примите его ответ как правильный, так как я собираюсь только остановиться на этом.

Обычно вы используете токен доступа в слоях интеграции , где вам необходимо авторизовать доступ. Веб-API и другие контроллеры представления, например. Обработчики сообщений при использовании очередей сообщений не должны предоставляться публично, поэтому для них обычно не требуется авторизация.

Из того, что я могу сказать, в вашем случае вам необходимо получить доступ к внешнему хранилищу с помощью токена доступа, чтобы получить Speci c данных. Это означает, что токен доступа может истечь до того, как будет предпринята эта операция.

На мой взгляд, у вас есть 3 варианта:

1) Вы получаете соответствующую информацию в начальной точке интеграции, скажем, Контроллер веб-API, а затем передать эти данные.

2) Вы передаете имя пользователя и используете своего рода учетную запись службы , чтобы получить токен доступа для пользователя, у которого есть учетная запись службы. имеет разрешение делать это от имени пользователя, а затем использовать токен доступа для получения соответствующих данных.

3) Возможно, учетная запись службы имеет возможность собирать эту дополнительную информацию для пользователя, и в этом случае учетная запись службы проверяет подлинность для получения токена, а затем запрашивает данные для соответствующего пользователя.

В предыдущем проекте, в котором я участвовал, нам пришлось использовать сервер интеграции webMethods , на котором внутренняя команда использовала токен ADFS. Токен имел 8-часовой срок действия, и некоторые операции выполнялись только по истечении этого времени по разным причинам. Токен с истекшим сроком действия будет обновлен для пользователя, поскольку учетная запись службы имеет некоторые формы прав делегирования в ADFS. Я не был вовлечен в эту реализацию, но в целом это была идея обойти эту проблему.

Если вы не можете заставить учетную запись службы обновить sh токен или получить необходимые данные напрямую, я полагаю, опция (1) будет вашим лучшим выбором.

Answer 2

Сохранение токена доступа пользователя и токена обновления не является проблемой для бизнеса / домена. Я бы сказал, что вы не должны пытаться справиться с этим через DDD. Если вам нужен токен доступа в CommandHandlers, я бы поместил логи c, относящиеся к токену доступа, в какое-то промежуточное программное обеспечение за пределами домена.