MVx - UI-ная часть клиента

Тогда в чем разница, если MVx не только про UI, но и про Model тоже

UI != View

Model в MVx - это интерактор в терминах clean

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

Т.е. бизнес-логика

Я своим коллегам рисовал такую картинку. Там только ошибка - от интерактора к презентеру ромбик должен быть (композиция), а не стрелка (наследование)

Большой прямоугольник UI - это "Vx" часть от любого MVx

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

sealed class FetchDataResult<T>
data class Success<T>(val data: T) : FetchDataResult<T>()
data class Failure<T>(val message: String, val cause: Exception? = null)

: FetchDataResult<T>()

вполне

ок, спасибо

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

там в домейн слое еще должны быть entities

что в данном контексте значит "рендеринг"?

Засунуть текст в textview и картинку в imageview

т.е., например, когда мы из фрагмента подписываемся на стейт типа такого:
       viewModel.stateLiveData.observe{
           binding.myTextView.text = it.newText
       }
это и есть рендеринг?

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

понял, спасибо

Может binding звучит норм?)

С учётом того что уже есть viewbinding - средне.))

Всем доброго времени суток)
Есть вопрос по навигации между экранами разных фич во многомодульном проекте, разделение на модули по фичам согласно подходу из статьи: habr.com/ru/company/kaspersky/blog/520766/ (для каждой фичи есть модули api и impl)

Раскрою свой вопрос на примере абстрактного приложения для просмотра статей. Существуют следующие фичи: поиск статей, избранные статьи, просмотр конкретной статьи. Поиск и "Избранное" используют фичу просмотра, когда пользователь выбирает статью.

Какое api должно предоставлять фича просмотра статей и где должна происходить навигация на экран просмотра?
Навскидку я вижу два варианта:
1. Метод api принимает Router/FragmentManager, навигация выполняется в имплементации фичи просмотра
2. Метод api возвращает Screen или Fragment, навигация выполняется внутри фичи, инициирующей просмотр статьи

Какой вариант предпочтительнее? Есть ли ещё варианты?
Навскидку второй вариант выглядит логичнее, но подозреваю, что у него есть менее очевидные подводные камни)