И еще один вопрос
Где стоит ловить ошибки при запросе в сервис в Repository или в Контроллере или в том и в другом  с точки зрения архитектуры

Это уже к мобильным клин-гуру. Но я бы сказал, что ловить надо там, где вы можете их обработать. Если вы ловите ошибку, вы должны как-то ее пробросить в UI или исправить на месте. Если вы ловите ошибку, чтобы прокинуть другую ошибку- ну так себе. Но это опять же с точки зрения Kotlin. Ортодоксальная Java к примеру любила типизированные ошибки

В одном слое ловить ошибку сделать что то , потом перебросит в другой слой не противоречит к принципам KISS и DRY,  что скажете с точки вашего зрения

Страуструп хорошо писал про обработку ошибок.
Ошибка - это ненормальное выполнение программы. Если у вас что-то передаётся дальше между слоями, то, наверное, это должна быть "нормальная" информация.

Я уже сильно древний для всех этих принципов, только здравый смысл остался. Вопрос ведь в том, что такое ошибка. Это сообщение о том, что операция не удалась с детализацией почему она не удалась. Если заворачивание этой ошибки во что-то добавит новую полезную информацию - это можно делать. Если нет, то это бесполезное усложнение.

Все это не относится к IO.

В остальном правильно, конечно.

IO? Почему нет?

Input/output - это обычные строчные данные. Текст.

@ynikitenko_chat @noraltavir Спасибо

и даже понятно почему: если у нас отдельная обработка ошибок где не надо, то это целых две логики вместо одной (обработки нормальных данных).

Потому что как раз для IO ошибка может быть нормальным состоянием. Ты не знаешь заранее удастся операция или нет. И ошибка должна быть обработана. А дальше вопрос в том, что нужно для обработки ошибки. Если содержание не важно, можно вернуть null и на этом успокоиться. Если содержание важно, то ее надо прокинуть до того места, где ее можно обработать. К примеру ошибка подключения бывает разной. Это может быть "сервер недоступен" или "неверный запрос". Оба ответа вообще говоря могут по разному отображаться в UI.

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

Ну оно далеко не всегда так работает. Может оказаться, что ты что-то не предусмотрел. Тогда тебе при новой хотелке в UI надо лезть внутрь модуля обмены сообщениями, ломать API, добавляя новые типы результата и меняя все обработчики по дорге и делать вообще нелокальные изменения. Не говоря о том, что тогда надо возвращать какой-нибудь Either и делать кучу плясок с ним. Этот подход имеет право на жизнь. Но не очень прагматично.

Это пример плохой архитектуры.
Слоистая как раз изолирует изменения. Тип может поменяться между двумя слоями, это не страшно.

Thanks

Ну я выразил свое мнение на основе своего опыта разработки. У меня не очень много опыта именно мобилок (хотя есть), но я думаю, что там, то, что я сказал еще более актуально

Ну возможно это я ошибаюсь и думаю, что архитектура это про все приложения ;)
Я для мобилки ничего не знаю, только сайты немного писал (но там как раз визуализация, вёрстка).

Не за что, удачи! Можете просветить что получилось)