В Android разработке много отклонений от чистого понимания Чистой архитектуры, так как архитектура, описанная Робертом Мартином в некоторых местах в Android не столь удобна.

Здесь описана чистая архтектура примительно к Android: https://github.com/AndroidArchitecture/AndroidArchitectureBook/blob/master/theory/Theory_article.md

Пункт 3: "Есть несколько вариантов трактования понятия "Репозиторий". Подробно можно почитать, например, здесь. В Андроид-мире "Репозиторий" - это абстракция для получения данных, то есть она скрывает, с какого именно источника получены те или иные данные.
Кроме того Репозиторий может внутри себя реализовывать логику кэширования данных и соответственно выдачи либо закэшированных данных, либо данных с сети."

Я могу быть не прав
Я лишь предерживаюсь описанного в данной статье подхода

Сначала размазываем стейт по слоям, потом непонятно как его обработать

да, прикольно, но это не имеет смысла)

+

Можете пояснить, пожалуйста

Максим нормально пояснил)

Видимо не правильно интерпретировал сообщение Максима
Для меня размазывание логики по слоям это вынесение логики работы с данными в интерактор

Когда в интеракторе может быть более 300 строк кода логики и без логики получения данных

ProfileRepository {
fun getFreshProfile()
fun getCachedProfile()
fun getFreshOrCachedProfile()
}

вот такой репозиторий появляется, если прятать от бизнеса источник данных

Нет

Получается примерно такой:
ProfileRepository {
fun getProfile()
}

В самом крайнем случае можно добавить флаг у метода Repository. Но мне кажется, что это редкий кейс

что убирает смысл каких либо абстракций)))

Иначе получается, что в интеракторе слишком много логики
Учитывая, что некоторые ещё и маппят данные в интеракторе, то плучается, что интерактор отвечае почти за все

Ребят, а на сколько допустимо по клину, чтобы у меня один "менеджер" знал про репозиторий? Ведь оба два берут на себя работу с реальными зависимостями, допустимо ли чтобы имплементация менеджера знала про интерфейс репозитория?

Какой получается репозитоорий, если не прятать от бизнеса источник данных?

Тогда это лучше назвать не репозиторий, а как-то типа DataSource. И оно будет принадлежать слою бизнес-логики.
Репозитории лучше держать чистыми. Т.к. возможна ситуация, когда вся эта логика кеширования не нужна будет каким-то интеракторам, либо нужна будет другая.

Размазывание логики - звучит странно, логику можно описать функцией и поместить где угодно, от её местоположения работать по другому она не станет. А если у нас стейт где угодно, тут и начинается "что у нас репозиторий, а что интерактор"

load/save (db), pull/push (net)

Чем Repository отличается от DataSource тогда?