Привет, в качестве примера реализации clean нашел этот проект

https://github.com/android10/Android-CleanArchitecture-Kotlin

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

Нарушение - да. Но, imho, не супер-критичное нарушение.
Я часто такое встречал. Просто часто не хочется писать мапперы из-за лени или для (преждевременной) оптимизации. И на уровень domain проникают модели из data-слоя со всякими аннотациями (от retrofit или room), которые намекают на способ получения этих данных. В идеале, да, так лучше не делать.

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

Вот это - да, как-то совсем странно

Привет! Ребят, если у меня результат работы юзкейса - это некоторый объект класса Wallet, для создания которого требуется Context, я могу в юзкейс инжектить WalletBuilder интерфейс, а уже в саму реализацию строителя инжектить контекст? Это будет нормальным решением, чтобы не не поставлять контекст в юзкейс?

Зачем ему context?)

Нужно библиотеки за протоколом

Всем привет! Вопрос в следующем, вот например, есть основной фрагмент, в котором отображаются элементы recycler view. Этот список с данными можно сортировать различными способами. Сама архитектура хотелось бы, чтобы была MVVM.
Чтобы открыть список фильтров вызывается BottomSheetFragment. В который загружаются динамически списки фильтров. Как посоветуете реализовать такой функционал(архитектуру), чтобы и состояние фильтров хранилось, и чтобы любой ивент, связанный с переключением фильтра, вызывал сортировку или загрузку данных в recycler view?

я недавно тестовое делал, не совсем до конца доделано, нет кеширования в бд и навигации нормальной, но можете глянуть))
я там мапплю в репе, но по хорошему я бы еще датасорс на уромне api модуля закрыл чтобы абстрагироваться от моделек с аннотациями
github.com/jokerxt/TranslationSearcher

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

если есть даггер то лучше в нем создать объект с передачей контекста

Даже если его прятать за абстракцией.)

Я его не "тащу в домейн". Он у меня есть на уровне реализаций интерфейсов -> это не домен

Разве юз кейс это не домен?)

Иногда он нужен в data-слое. В этом случае его нужно использовать только в реализации репозитория

это больше  о дата слое, как по мне

В дата слое может быть контекст.

Ну вот же, это где-то тот случай. Просто что Wallet не есть репозиторий - он проводит транзакции и баланс может отдавать

Значит он должен инжектить в себя некую сущность, которая в реализации будет использовать контекст

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