Маппировать - до передачи в UseCase, ещё в дата слое.
Если делать маппинг в UseCase, то получается, что он зависит от DTO из запроса

То есть, получается такая цепочка: Данные Из View --> ViewModel/Presenter (если они нужны). Здесь они превращаются в промежуточный объект для UseCase. --> UseCase --> Repository. Здесь данные превращаются в объект для IO. --> IO.

Ответ: IO --> Repository. Здесь данные превращаются в бизнес-объект. --> UseCase. Здесь данные превращаются в объект для ViewModel/Presenter (а может передаваться и тот же DTO). --> ViewModel/Presenter --> View.

Я правильно понял?

У меня во фрагмент уже лайвдата приходит, dispose делаю в onCleared() у viewmodelи

Вопрос к знатокам по неймингу? Все называют данные dto, потому что они передаются между слоями?

Мое мнение, что dto это именно перемещаемые объекты и больше подходят для data слоя.
В domain лучше назвать классы данных Entity, и позволить им в редких случаях иметь вспомогательные методы.
В presentation слое использовать Model для отображения.
А для передачи между экранами использовать например Data.

А то часто встречал, что по всему проекту летают разные dto и непонятно это dto какого слоя.
А вы как делаете?

Но ведь выносить компоненты Андроида в другие слои не очень здорово?

В domain слое нету никаких мапперов. Дто маппится в репозитории. В presenter прилетает объект из доменного слоя и там отображается сразу или после небольшого форматирования(вставить в строку из ресурсов например)

Так вьюмодель и фрагмент в одном слое

А, то есть ты где-то в use-case превращаешь данные в LiveData, которые потом уходят в ViewModel?

Ты отдаешь данные из useCase во вьюмодель и там уже превращаешь в live data

Понял. Спасибо большое всем

А по неймингу ты как делаешь? Все dto?

Да именно так, во вьюмодели получаю данные асинхронно через rx и присваиваю их в лайвдату

В Domain – entities. в Data-слое обычно Response. Аббревиатуру DTO ни в каком слое не пишу, просто на словах привык так говорить

А. Ок. Просто в текущем легаси проекте dto это любой класс с данными)) И вот интересно, только ли у нас так или это общепринятая практика)

А нормально ли "тащить" данные в в обёртке типо <Success, Failure> прям до ViewModel и там уже отобразить их во View? Или всё-таки нужно ещё до этого "развернуть" обёртку в entity бизнес-логики? Особенно интересует это, чтобы понять где обрабатывать результат suspend функции.

Мне кажется эта обёртка нужна только для expected ошибок, чтобы их в бизнес-логике обработать.

У нас rx, с корутинами не работал, так что не знаю как там это конкретно реализовывается.
Ты в репозитории получаем данные или ексепшен. Исключения проверяем, можем ли их обернуть в ожидаемые исключения, и пробрасываем через onError. В интеракторе логика получает данные, работает с ними и если получается ошибка логики, то отдается <Success, Fail>. В презентере обрабатываются хорошие данные и ошибки логики. А ожидаемые исключения пробрасывается в ErrorHandler и там обрабатываются одинаково.

Мне понравился доклад про ошибки, рекомендую.