REP/CCP/CRP/DAG

Что-то подобное да

F

хоть где-то это есть

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

можете у кого-то есть пример хорошей реализации архитектуры Retrofit-RxJava-Room?

привет всем. какой скоп лучше дать репозитории? Singleton или ActivityRetainedScope?

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

Разве оно исключает друг друга?
Мы в делим на фичи (фича - отдельный модуль), а фичи на слои. Есть подход без слоёв?

скорее всего имеется ввиду когда целое приложение делится именно по слоям (не по фичам).
Тогда появляется папка Presenters, в которой лежит 30 presenter'ов.
Работать с таким проектом - "одно удовольствие".

А не работать с такими - еще большее удовольствие

Осваиваю сейчас на практике buildFlavor'ы.
[MVVM] Есть экран со списком и кнопкой "добавить", в расширенной версии хочу добавить LongClick. Я могу расширить View и ViewModel.
Могу ли я как-то в расширенной View указать явно, что теперь у нее AdvancedViewModel ViewModel, чтобы не кастовать каждое обращение?

Для наглядности
вопрос про нижний ряд, как сделать красную стрелку?

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

это приведет к тому, что у Вас будет 30 модулей presenterX. Если делать это необдуманно

для этого и нужны REP, CCP и CRP

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

Не исключает конечно, дело добровольное. Я не оперирую понятием "слой", и не задумываюсь условно "в каком слое должен быть маппер из одного слоя в другой". Разделяю по ответственностям.

Просто как мне кажется , тогда лишние запросы в руки пойдут при изменении конфигурации. А если репа в синглтоне, она это переживет

значит у Вас проблема с разделением по слоям. Так как репозиторий вообще никак не реагирует на конфигурацию
Он вообще ничего про платформу не знает

Где в mvvm лежит стейт ? Вью модель это же слой презентации - это же то что нужно отображать. Где тогда лежит сам стейт?