По существу вопроса - я бы не называл 1 data source'ом. Т.к. это может пересекаться с другими сущностями. Например, популярная библиотека для пагинации paging library использует понятие data source на уровне UI (в презентере).

1 - Gateway 😁

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

Нам хотя бы в рамках чата определиться с терминологией. А то постоянно возникает недопонимание кто о чём говорит.
Потом можно будет ссылаться на картинку и уточнять кто что имеет в виду.

Еще раз пересмотрел твою схему и не пойму в чем задача энтити 2, если они вызываются из интеракторов

Ранее обсуждалось, что может быть некая сущность, которая объединяет несколько источников данных для той же модели. Т.е., например, результат запроса и запись в базе, которые мапятся на одну ту же модель.

Кину в затравку своё представление слоёв

Слои общаются между собой с помощью интерфейсов (хотя часто не делают интерфейсов для юзкейсов\интеракторов)

View - меняем на любой презентейшн паттерн
Далее идет UseCase/Interactor (бизнес-логика), в зависимости от того что нужно сделать
Грубо говоря Use Case - это один экшн, а Interaсtor - объединение нескольки юзкейсов
Задача Repository - агрегировать источники данных и возвращать результат

вот это по мне, в репу инжектится 2 датасорса
тоже поддерживаю)

Поддерживаю

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

Потому что тогда юзкейсу\интерактору прийдеться заниматься логикой кеширования\сохранения в бд\префы
А мы же выделяем сущность, т.е. репозиторий который отвечает за всю обработку\сохранение данных и возвращает уже готовую к использованию модель

тогда будет что-то подобное

у репозитория А будет методы фетч1, фетч2

и надо будет сделать юз кейс, который будет дергать а.фетч1 и все
собственно зачем

если можно просто в юз кейсе с названием фетч1 сделать всю логику по обработке и сохранению, заинжектив туда базу данных и интерфейс апи

В вашем случае, юзкейс это тупая обёртка, которая ничего не делает, кроме как возврата результата с сервера\бд и тд.
Но как только появляется бизнес логика, всё усложняется и получится каша

Получается что в домейн слой втягиваются зависимости из дата слоя и смешивается бизнес-логика с логикой сохранения\кеширования данных (нарушение single responsibility), о чём домейн собственно даже не должен знать.
Вообще архитектура зависит от бизнес требований, так что ничто не мешает вам сделать по вашей схеме, но ничто так же не мешает в интерфейсе репозитория сделать метод который вернет данные из конкретного источника или пробросить какой-нибудь флаг

Всё это допустимые варианты

+

Всем привет.Я новичок и у меня есть небольшой вопрос - вот у меня есть view(fragment), viewModel и модель. Я объясню как я делаю прослойку модели и буду рад если мне объяснят что я делаю не так. Я делаю отдельный класс - например FlowerRepository(закачивается список цветок из интернета и кладется в room),в него инжектирую ДАО и базу данных(всё что нужно для работы,в том числе и ретрофит). сам этот репозиторий инжектирую во viewModel и там уже вызываю функцию репозитория. Вопрос в следующем - что я делаю не так?Как я понял, репозиторий и другие классы должен связывать интерфейс каким-то образом. Я пытаюсь понять эту идеологию с моделью,но информации в интернете очень много , глаза разбегаются и я не вкуриваю на 100%. По моей методе приложение работает,но я хочу сделать ещё правильнее. Буду рад,если мне помогут разобраться.

В закреплённом сообщении  есть достаточно материалов

Вот есть у меня контроллер (как фрагмент, только в кондукторе), там написана логика, которую я хочу переиспользовать с разным гуями. Как мне лучше докинуть функцию, создающую вью, до onCreateView?
Абьюзить наследование? Передавать парселабельную функцию? Есть ещё варианты?..

> парселабельную
> функцию
Шо?..

Перепеши все на композ.) и кидай композ функцию.)

Я через наследование делаю и от него уже наследую контроллеры..