В том, что то, как ты отправляешь данные на сервер — это как-раз детали реализации. На них не завязана бизнес-логика.

Но те данные, с которыми будет работать сервер\бизнес-логика приложения это уже совсем другое.

Причём — выбор между JSON\XML\etc ещё на уровень выше, чем, например, выбор средства для перевода данных в нужный формат. Т.е., то что ждёт сервер — это не тоже самое, что выбор библиотеки для создания json'ки. По хорошему, если бы обычно это не было лишним занятием, то это тоже можно было бы абстрагировать.

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

>Почему sha(login+password) - это бизнес-правило
Потому что у тебя есть конкретное бизнес-действие — авторизация. Детали которой говорят тебе о том, что тебе нужно на сервер отправить именно эту строку. Там же могут быть детали о том, чтобы не давать пользователю использовать пароль короче 8 символов.

Это не те же детали реализации, в которых ты выбираешь "а как хэшировать".
Детали реализации тут могут быть в виде выбора средства для хэширования (встроенные в андроид, сторонняя библиотека, свой велосипед), но это всё ещё не уберёт уже определённую бизнес-логику завязанную на алгоритм sha256 (в нашем кейсе).

(Ты вроде выше говорил, что не хочешь спорить, но когда мы пришли к тому, что у нас разных взгляд — продолжил:))

Несколько сумбурное сообщение вышло, слишком намешал всё в кучу:)

Я понял ваше мнение, спасибо за детальное объяснение. В нашей беседе раньше было мало конкретики и причин - поэтому обсуждение казалось бессмысленным продолжать.

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

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

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

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

>Если я верно понял, то вы рассматриваете мобильное приложение исключительно как часть всей системы без возможности рассмотреть его как самостоятельную часть.

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

В этом и был мой изначальный посыл, что утверждать "hash и соль это задача репозиторного уровня" — не правильно, т.к. задачи, кейсы и решения бывают разные.

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

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

>если сервер захочет принимать что-то другое

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

>Если я верно понял, то вы рассматриваете мобильное приложение исключительно как часть всей системы без возможности рассмотреть его как самостоятельную часть.

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

Но имеет право существовать

бизнес-логика осталась такой же - авторизоваться по логину -паролю :)

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

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

Беда в том, что авторизация у нас, в этом кейсе, идёт не по логину и паролю, а по нашему хэшу.

по хешу она идет на сервере, в домен слое - по логину/паролю

А я говорю всё в домейне.
За альянс!

ну ок, главное, чтобы твоё неведение не мешало коллегам xD

В таком случае если мы способны унести шифрование в репозиторий - то почему ей не пользоваться?

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

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

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

Беда в том, что в этом кейсе выше — это тоже суть.

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

Как выше спросил — проверку длины пароля тоже вынесите в data?