google samples

splitties.init

??

А, прикольно. Но я за менеджмент таких штук своими руками максимально, не люблю плодить зависимость просто так. Но спасибо

очень удобная и простая вещь,  можете смело плодить😊

Как минимум задумаюсь написать такое свое, спасибо 😄

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

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

Если таких случаев не предвидится, используйте любой MV* + дата-слой, как гугл рекомендует и не будет проблем

Если нужен домен - то он будет просто проксировать вызовы в дата-слой группируя их по сущностям или по экранам

Далеко не во всех приложениях именно такая ситуация

Например, в банковских приложениях в Interactor'ах много логики
В других крупных приложениях есть необходимость в Interactor

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

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

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

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

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

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

Возникают такие вопросы:
1. Каждый ли слой должен иметь свои DTO в идеале
2. UseCases/Interactors - это описание функциональности приложения? То есть то, что оно вообще может делать, я правильно понимаю?
3. Какую логику должен содержать интерактор, а какую entity в таком случае

Мне кажется, что clean был придуман с прицелом на немного другой тип приложений, и многое из него для мобайла вообще ненужное и лишее.

Согласен
Clean не полностью подходит для мобайла
Банально то, что UseCase в идеале это класс с одной открытой функций далеко не всегда удобно
Хранить логику в Entity тоже как правило не удобно

Чтобы понять Clean относительно Android можно загуглить "GitHub Android Clean Architecture Book"

Если по канону про модели данных, то так:
1. в домене должны быть модели данныых, которые отдают репозитории
2. в дата слое должны быть свои DTO для сервера и для базы данных (желательно разные) и конвертер из них в модели данных домена.
3. в презентейшене можно смело использовать доменные модели

Про UseCases - это про бизнес-логику: если у вас вся логика приложения - это скачай и отобрази - то класс пустой-прокси. А если логика “для юзера с правами доступа покажи много данных, для юзера без прав - подбери мало” - то вот это вот и надо делать в домене, хотя иногда можно и в презентере - не канонично, зато просто)

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

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

нашел только какой-то древний сэмпл book store