Чистая архитектура и авторизация.Правильный путь?

Question

Я работаю над приложением Android, используя шаблон чистой архитектуры, и у меня есть сомнения, как правильно реализовать авторизацию.Является ли следующее решение чистым с точки зрения чистой архитектуры?

Я бы создал варианты использования, как показано ниже (выполняется из уровня представления):

• LoginUseCase (для предоставленных выборок логина и пароля)токен API через удаленный сервис и сохраняет в локальном источнике токена)
• LogoutUseCase (очищает токен от LocalTokenSource)

(интерфейс LocalTokenSource будет храниться на уровне домена иего реализация в слое данных - своего рода хранилище)

И чтобы обновлять токены при каждом запуске приложения (это не случай использования с точки зрения пользователя, верно?), я бы создал компонент SessionManager в доменеслой.SessionManager будет отвечать за обновление токена и сохранение его в LocalTokenSource.Каждый раз, когда начинается действие, от его докладчика я выполняю refreshToken() для введенного SessionManager. Что вы думаете о решении?

Если оно чисто, то как обрабатывать передачу токена удаленной службе для выполнениядругие методы API, которые требуют токен?Допустим, у меня есть PostsRepository, который выбирает данные постов из удаленного сервиса.Должен ли я передавать токен из прецедента в метод репозитория, например repo.getPosts(token)?Или введите LocalTokenSource в хранилище, чтобы он мог читать токен самостоятельно?Не будет ли второй вариант нарушать правила чистой архитектуры, потому что LocalTokenSource будет использоваться в 2 слоях?

Answer 1

Главный вопрос, который вам нужно решить: хотите ли вы смоделировать авторизацию (и, следовательно, использование токена) в качестве аспекта вашей бизнес-логики ИЛИ хотите ли вы рассматривать это как «детали реализации».

Если вы решите для первого, выделив для него сценарии использования, добавление SessionManager на уровень домена и передача токена в хранилища будет согласованным моделированием.

Если вы решите дляпозже вход в систему / выход из системы / обновление, а также существование токена, вероятно, лучше всего хранить "за сценой", поэтому на уровне структуры или шлюза.

Оба подхода будут следовать правилам Чистой архитектуры (до тех пор, пока вы не нарушите правило зависимости).