Привет, ребята, у меня тут философский вопрос. Суть моб. приложений

(по крайней мере у меня) сводится к тому, что мы просто гоняем данные туда-сюда, через рест например, и что-то показываем пользователю. В таком случае зачем нужен domain слой? Во всех примерах что я видел entity - это просто dto, без какой-либо логики. Что делает Interactor/UseCase таким необходимым компонентом?

У вас получается браузер, без логики. Польза от domain-слоя для вас только в гипотетическом будущем, когда не получится логику зашить на бэкэнд и нужно будет всунуть ее в приложение. Если таких случаев не предвидится, используйте любой MV* + дата-слой, как гугл рекомендует и не будет проблем

Далеко не во всех приложениях именно такая ситуация Например, в банковских приложениях в Interactor'ах много логики В других крупных приложениях есть необходимость в Interactor Банально нужно авторизоваться пользователю, а на сервер отправлять не логин и пароль в чистом виде, а использовать hash с солью и результат отправить на сервер. Вот уже логика в Interactor появляется

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

Это дискуссионный вопрос)

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

Репозитории - максимально тонкие обертки над данными. Презентер управляет view. Всё, что между - бизнес-логика. Бизнес-логика объединяет разные репозитории. Берет данные из одних, кладёт в другие. Банальный пример - отправить запрос дёрнув метод репозитория. Потом, оказывается, надо ещё настройку сохранить. Где сохранять? Репозиторий не должен знать о настройках. Презентер тоже, т.к. его задача - управлять view. Остаётся интерактор.

Чут по-моему звучит немного наоборот. Разве решение куда сохранять данные - это дело интерактора? Это ведь не бизнес логика. Имхо это лучше делать как раз в репозитории

наверное имеется в виду что-то вроде сайд-эффекта, помимо сохранения самих данные нужно сохранить еще что-то

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

ну, звучит логично. Но на куче примеров видел обратную историю. Ох уж этот клин - у каждого он свой)

тогда и откуда брать данные - из кэша или из реста - надо решать на уровне интерактора получается

ну тонкие это datasource, а репозиторий фичи берет разные datasource и что-то делает, тк это не бизнеслогика

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

Странное утверждение. Бизнес логика есть бизнес логика. Если тебе в ТЗ\таске\доке пишут, что авторизация выполняется посредством SHA256(username + password + salt), то это и есть бизнес-логика. Выносить это в репозиторий в данном случае некорректно.

И если требуют шифровать данные в базе данных пишут в ТЗ - то тоже в домен выносить?

+

Выносить в интерактор

Хранение данных не относится к бизнес логике.

Как и формат передачи данных для авторизации. Это же интеграционный вопрос системы.

такая себе бизнес логика

Обработка данных — бизнес-логика. В кейсе выше вполне себе могла быть бизнес логика (читай интерактор\юзкейс) который шифровал бы данные и отдавал дальше на хранение в data. Так и хэширование данных для дальнейшей передачи на сервер.

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

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

Я руководствуюсь таким признаком. Что если поменяется правило хэширования, шифрования? Если я для тестов захочу убрать шифрование - повлияет ли это на поведение приложения? Выглядит как замена базы данных, auth manager’а или любой другой способ получения авторизации. Значит это транспорт и слой данных, а не бизнес

И на сервере сам поменяешь всё? И на других системах?

Нет, я в своем приложении буду тестировать бизнес слой и передам ему репозиторий без шифрования.

А к чему этот репозиторий без хэширования, если у тебя сервер ждёт именно такие данные?

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