Получается что надо три типа моделей? Одни для сети и бд, которые в дата модуле, а в домеин третий тип, который юзается в presentaion
Так?

Да

Спасибо

@massivemadness а ведь если модели слишком раздутые и много сложных типов то мапить каждый раз их при получении с базы - наверн снижает производительность..

можно мапить только то что нужно

Да в любом случае там счёт идёт на наносекунды (может конечно преувеличил, но на миллисекунды точно)

Понял

Все мапят это дело ручками или может есть средства какие то?

Нуу да, создаёшь какой нибудь object Converter и делаешь там конвертацию

Ну по крайней мере лично я так делаю

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

Выглядит как DI-костыль для бедных. Типа "мы не верим, что вы сможете настроить общение экранов через модель поэтому вот вам возможность подоткнуть что-то из активити". Область применения очень ограниченная.
А если я хочу из VM второго экрана слушать первый, а не из фрагмента, чтобы какую-то дополнительную логику навернуть? observeForever страшный использовать?
А если я хочу чтобы вьюмодель была пошарена на уровне родительского фрагмента?
"Fragments don't need to know about each other besides the SharedViewModel" - окей, то есть мне нужно делать модуль с пошаренной вьюмоделью и от него зависеть модулями моих фрагментов? Тут даже зависимость эту не развернешь, потому что ViewModel по интерфейсу не запровайдишь.
В общем, узконаправленное и весьма странное решение. Если оно действительно хорошо подходит под задачу - отлично, вопросов нет, но ощущение, что реально таких задач немного.

ну или вот с хабра статья https://habr.com/ru/post/337320/

Эти статьи описывают, как заинжектить зависимости во вьюмодель через даггер. Я не об этом говорил)

по пунктам не разложиш тогда?

Выше вроде разложил, и перед этим ещё дискуссия длинная. Вроде даже к заключению пришли) Если хотите что-то прояснить или уточнить, то лучше задайте конкретный вопрос.
Общая мысль: пошаренные вьюмодели решают очень ограниченный скоуп задач из коробки, и образуют странные зависимости между экранами. Той же функциональности можно добиться проще и менее костыльно, если организовывать общение экранов на уровне модели. Единственный профит от шаред вью модел - это то что их можно быстро запровайдить через activityViewModels. Но это годится скорее чтобы быстро наклепать прототип какого-то экрана чем для нормальной разработки)

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