Ну тогда Entity для domain должен возвращать только интерфейс, который лежит в domain слое, а это интерфейс репозитория получается. И в его реализации происходит маппинг всего и вся перед тем, как вернуть это в domain. А DataSource возвращает данные которые вернулись с сервера или из другого места. Мы их называем ExampleDto. Они могут повторять структуру Entity, а могут не повторять, но у них все поля нуллабл, и маппер разруливает ситуации, когда из нуллабл нужен nonnull в entity.

Так это понятно

Тогда в чем вопрос?))

Я сейчас о другом, придется писать маппер для каждого DataSource, в моем случае...

А у тебя datasource возвращают разные данные в зависимости от ситуации?

Именно, если смотреть на сырые данные: при парсинге мы получаем лишь String (исходник странички из сети, например), при норм api получаем уже структурированный Response и т.д.

Но так как интерфейс для всех DataSource один и все они его имплементируют, независимо от источника, то маппить придется непосредственно в DataSource

ну, я пока так думаю

Ну да. У тебя в любом случае придется писать мапперы для каждого типа из sorce. Тебе и стринг нужно спарсить и response

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

Ты главное логику маппинга в отдельный класс вынеси)) А где его заюзать, потом разберешься)

Та у меня это тоже интерфейсы)

Я иногда думаю что это оверхед клинить в приложении с 20-тью фичами...

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

Три.нн Ь

Screenshot (Jul 23, 2019 2:03:08 PM)

Подскажите, пожалуйста, ваш опыт. Приехало приложение на поддержку со структурой "хорошо что вообще работает". С заказчиком договорились о реструктуризации. С какого места лучше вводить di? С fragment или application?

С Application.

Получается мне придется хранить по 2 объекта db и api? Один в модулях, один для текущей структуры?

Почему это по 2?