У тебя есть endpoint у сервера для авторизации. Он ждёт

от тебя одну единственную строку в теле запроса, которая представляет из себя sha(username + password).

Сервер именно так авторизует.
Ему не нужны голые логин и пароль ни в каком виде.

Причём тут детали реализации, если теперь на этом всё завязано и это явная бизнес-логика?

С точки зрения бизнес-слоя сервер ждет логин и пароль:) все остальное - деталь. Эндпоинт, шифрование, GET/POST

Вот именно, что нет. В данном кейсе сервер ждёт именно хэшированную строку. Это полноценное бизнес-правило из которого вытекает конкретный юзкейс.

У нас разный взгляд на эти вещи) я не вижу причин почему это бизнес-правило.

Ничего страшного. Главное, чтобы твоё неведение не мешало коллегам:)

Это уже переход на личности. Вот скажи, если сервер ждет XML - это тоже бизнес-правило?

Что? На какие личности, ты что придумываешь то:) >если сервер ждет XML - это тоже бизнес-правило? Нет.

Почему sha(login+password) - это бизнес-правило, а xml/json нет? В чем отличие?

про личности зря, автор ничего плохого не говорил.

«Чтобы ваше неведение не мешало коллегам», слишком сильное утверждение

> я не вижу причин https://t.me/Android_Architecture/103589 > Ничего страшного. Главное, чтобы твоё неведение не мешало коллегам https://t.me/Android_Architecture/103590 Вы уверены ?

В том, что то, как ты отправляешь данные на сервер — это как-раз детали реализации. На них не завязана бизнес-логика. Но те данные, с которыми будет работать сервер\бизнес-логика приложения это уже совсем другое. Причём — выбор между JSON\XML\etc ещё на уровень выше, чем, например, выбор средства для перевода данных в нужный формат. Т.е., то что ждёт сервер — это не тоже самое, что выбор библиотеки для создания json'ки. По хорошему, если бы обычно это не было лишним занятием, то это тоже можно было бы абстрагировать. Причём, заметь, я ничего против реализации в репозитории не сказал. Этот подход тоже имеет право на жизнь, но тогда ты разбиваешь общую логику и раскидываешь её в разные места. >Почему sha(login+password) - это бизнес-правило Потому что у тебя есть конкретное бизнес-действие — авторизация. Детали которой говорят тебе о том, что тебе нужно на сервер отправить именно эту строку. Там же могут быть детали о том, чтобы не давать пользователю использовать пароль короче 8 символов. Это не те же детали реализации, в которых ты выбираешь "а как хэшировать". Детали реализации тут могут быть в виде выбора средства для хэширования (встроенные в андроид, сторонняя библиотека, свой велосипед), но это всё ещё не уберёт уже определённую бизнес-логику завязанную на алгоритм sha256 (в нашем кейсе). (Ты вроде выше говорил, что не хочешь спорить, но когда мы пришли к тому, что у нас разных взгляд — продолжил:))

Я понял ваше мнение, спасибо за детальное объяснение. В нашей беседе раньше было мало конкретики и причин - поэтому обсуждение казалось бессмысленным продолжать. Если я верно понял, то вы рассматриваете мобильное приложение исключительно как часть всей системы без возможности рассмотреть его как самостоятельную часть. Моя точка зрения на проектирование архитектуры идет от конкретики мобильного приложения, а не всей системы в целом. Если следовать правилам слоев - то сначал мы делаем внутренний слой - бизнес-логику, где мы знаем что есть авторизация и для нее юзер отдает нам логин и пароль. Дальше мы можем собирать несколько версий нашего приложения. Для одной из них мы передадим репозиторий с сервером с шифрованием. Для другой - будем работать с Account Manager’ом. И эта замена ни на что не влияет с точки зрения приложения. Только с точки зрения всей системы.

так в домене у тебя fun login(name, password), не?) а sha это детали реализации

>Если я верно понял, то вы рассматриваете мобильное приложение исключительно как часть всей системы без возможности рассмотреть его как самостоятельную часть. Именно, что оно бывает разным. И в разных случаях будет разная реализация. Где-то хэширование пойдёт в бизнес-логику, а где-то в конкретную реализацию. А где-то и вовсе разобьётся на несколько юзкейсов, часть из которых будет это использовать как бизнес-логику, а часть как детали реализации. В этом и был мой изначальный посыл, что утверждать "hash и соль это задача репозиторного уровня" — не правильно, т.к. задачи, кейсы и решения бывают разные.

Проверка длины пароля тогда тоже в репозиторий уйдёт?

не обязательно, но это при чем? бизнес-логика у тебя авторизоваться и получить успешно/не успешно, а sha(login+password) это реализация (дата слой), если сервер захочет принимать что-то другое, то домен менять не потребуется

>если сервер захочет принимать что-то другое То значит и бизнес-логика изменилась. Вернее детали реализации бизнес-логики. Но это всё ещё не тоже самое, что детали реализации приложения.

Кажется, что бизнес-слой все же должен быть свободен от шифрования и других “защитных” мер. В противном случае мы усложняем самую суть и маскируем ее. От такого решения меньше пользы. Только потери в гибкости и простоте Но имеет право существовать

>Кажется, что бизнес-слой все же должен быть свободен от шифрования и других “защитных” мер Мне тоже так кажется. Но это вопрос десятый и он не убирает те случаи, где таким образом реализуют системы.

В таком случае если мы способны унести шифрование в репозиторий - то почему ей не пользоваться? Какая разница, что в ТЗ написали что “авторизация делается по строке, которая формируется хитрыми правилами”, если мы способны разделить это?

И зачем это? просто чтобы было? с таким же подходом люди мудрят по 10 слоёв в приложении, а потом ругают клин за избыточность:)

Ну как же, выше же обсудили. Чтобы упростить бизнес-слой, очистить его от шелухи и оставить только суть

Беда в том, что в этом кейсе выше — это тоже суть. Это не абстрагирование уровня "сейчас мы сохраним в shared'ы, а как дойдут руки сделаем нормальную sqlite табличку", это бизнес-правило которое говорит тебе "мне нужно именно это". Как выше спросил — проверку длины пароля тоже вынесите в data?

Валидацию входных данных? Я бы сделал в 2 местах: * на сервере (ответит 401/403) * поближе к UI в презентейшене. Сам валидатор можно сделать на domain-слое, но использовать его в presentation’е в use-case авторизации добавлять бы не стал, если туда передадут плохие данные - защитит сервер

Хорошо, видимо надо было с этого начать. Тогда у нас слишком разных взгляд на реализацию бизнес-логики:)

Я могу пояснить 🙂 как правило эта валидация привязана к каким-нибудь подсветкам поля пароля. Какой-нибудь password-power-meter красно-желто-зеленый. Надо там на каждую букву реагировать и менять эти цвета и получается, что в презентейшене валидация данных всяко будет. А передача по кнопке “submit” она будет одна, по клику и тогда уже use-case авторизации отработает

Можно просто входящие данные отправлять в domein для валидации, возвращать же структуру с ответом на валидацию и индекс неверного символа, далее ui уже на основе этих данных подсветит символ, это решания будет более маштабируемым и кроссплатформеным.

>как правило Не надо мыслить только стереотипами, выше уже говорил о том, что всё бывает очень разным. От того, что "как правило" где-то что-то как-то делается — не значит, что везде надо делать так. (но и в целом, к счастью, это далеко не стандарт и чаще делают именно по заполнению полей или нажатию кнопки. когда у тебя валидация идёт на каждый символ — это ужасно)

Опередил:)

Я же это и описал 🙂 без деталей какую схему возвращает валидатор в ответ. Что есть валидация на ввод нового символа, а есть вызов завершающий, на клик в кнопку А на кнопку после валидатора можно отправить уже в use-case “сделай авторизацию вот тебе input”. и там ответ будет не валидационный, а “успех/ошибка"

Это можно сделать и на каждый символ, если это необходимо.

Ты описал это так, что это не бизнес-логика, а какая-то там проверка у UI. Это разные вещи.

Тогда у тебя на каждый символ уйдет запрос авторизации - это уже ошибка..

Запрос уйдёт при нажатии на кнопку, проверку валидации же можно сделать реактивной (на каждый новый символ например) и тогда при нажатии можно уже сделать просто запрос на авторизацию.

И эта проверка будет все также в domein слое

Верно, согласен. https://t.me/Android_Architecture/103617 Так и написал:)

Плюсую. Единственное бизнес правило здесь это требование авторизации. Как оно будет выглядеть -- детали.