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

репо может отдавать entity или это должно быть что то отдельное?

вроде изначально между ними закладывалось различие, что entity - это логика предметной области, а interactor - логика работы вашего приложения. Например, реализация какой-нибудь векторной алгебры, или правил конвертации валюты - это entity, они не зависят от того, в каком приложении используются. А interactor определяют, что вы с этими entity делаете для достижения цели пользователя, как реализуете сценарии взаимодействия с ним.
Мобильные приложения в большинстве своём действительно достаточно просты, и декомпозировать на такое количество слоёв часто бывает нечего. Бизнес-логику и даже application-логику часто держат на бэкенде, поэтому вопрос “а что положить в интерактор” весьма справедлив.
Clean не навязывает количество слоёв, лучше постараться уловить идею, чем делать пахлаву.

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

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

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

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

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

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

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

я стараюсь datasource максимально абстрагировать от библиотек, чтобы наружу не торчали аннотации, но моделек получается больше)

похоже не на бизнес-логику, а на логику приложения, место которой в domain, если я правильно понял

сложная штука эта ваша архитектура

я не думаю что будет единогласное мнение по поводу , кто-то так делает, кто-то по другому, придешь в другую компанию а у них будет по третьему

коллеги, может кто поделится видео с последнего мебиуса, там был доклад про Флиппер... оч. хочется посмотреть?

Не будем забывать, что clean - это прежде всего, простота разработки и поддержки кода.
Если возникает необходимость полдня чесать репу и думать что куда поместить - то нафиг тогда этот clean?
По опыту репозиторий лучше воспринимать как тонкую обертку (=data source).
Объясню почему.
Вот вы, джедай клина, пишите репозиторий, который объединяет 2 дата-сорса (net и db). Ok, всё круто.
Потом приходит другой разраб. Ага, надо перед запросом прочитать настройку. Чешет репу, куда поместить дата сорс настроек. Аха, настройка связана с данным запросом, значит в репозиторий. Потом другой разраб хочет ещё один запрос сделать. Чешет репу, добавляет в тот же репозиторий. Третий разраб хочет ещё писать настройки ..

В итоге в репозитории получаются инжнкекты левых дата-сорсов, других репозиториев и другой хрени.
А потом... Этот репозиторий понадобилось переиспользовать, но без настроек. Что делает 4-й разраб? Правильно, добавляет флажки в параметры методов. Или того хуже, добавляет state в репозиторий.

Так что лучше всё-таки дать установку, что репозиторий - тонкая обертка. Чтобы не чесать репу что в него пихать.

То есть если сначала писать по клину, потом дорабатывать не по клину, то всё посыпется. Поэтому мы делаем вывод, что лучше сразу писать не по клину?

По клину, но с четкими установками и контролем :)

тогда и в первом случае ничего страшного не произойдёт

просто будет больше абстракций, хоть и результат будет один