Ребят, я правильно понимаю, что релизовать Parcelable на моделях данных из доменного уровня - неправильно?

используй Serializable 🌝

используй Serializable 🌝

Есть какие-то преимущества над Parcelable?

Да. Но это вроде как не критично, т.к. мы пишем под андроид :)

Да. Но это вроде как не критично, т.к. мы пишем под андроид :)

Большинство  компаний имеют свой кодстайл и требования, если же это тестовое задания, то наверное от тебя хотели просто понимания основ clean и Solid, если подумать то навигация в адаптер нарушает принцип  Solid (адаптер не должен отвечать за переходы), погуглил какие проблемы решаются если придерживаться этих принципов

@devStep
Вы наверное хотели сделать проще и короче.
В таких моментах, очень важно правильно ответить на вопрос, если он был канеш)

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

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

Пример: Список контактов, ContactsAdapter.
Есть навконтроллер внутри. По клику переходит например на ContactInfoScreen и показывает инфу о контакте, вся информация есть уже или передаем id - все ок.
Потом другому человеку пришла задача, написать звонки CallScreen например. Он смотрит на мокапы (дизайн) и там такой же список контактов. Супер! Ведь паттерн адаптер идеален здесь.
Ну максимум type другой подкину и покажу. Оценю я задачу на 12, по факту 30 мин делов. И идет чилить.
Пришло время делать, смотрит, на click по элементу надо делать переход на другой экран -> CallScreen ну лан пропишу логику в адаптере думает он. Type ж нет, пофиг context instance of погнали. И всё бы хорошо, ток потом оказалось надо чекнуть статус сети предварительно, чтоб не делать лишний переход на экран звонка.  Такс...
Прокину в адаптер какой-нить InternetConnectionHelper? Ок, есть какой-то синглтон(object), фух спасение.
А потом смена бизнесса, по клику на контакт нам ненадо делать переход сразу, мы вначале покажем диалог с выбором, а в диалоге будут все дейсвтия позвонить, удалить контакт и на разных экранах будут разные кнопки действия.  И уже от их нажатий будем чекать InternetConnectionHelper , но ток для CallScreen. Конец 😀.
Это все выдумано но вполне себе мб реальным кейсом. Более чем. И это ток 2 роута.
И кто бы что не говорил, какой бы Agile не был в тимах. 1 фиг все любят менять задачи, даже если у вас супер планирование!
Уже не говоря о стартапчиках и тд.

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

Бонусом.
Адаптер без доп зависимостей будет проще тестировать. Ваще возможно нормально тестировать др от друга. Иначе в тестах тоже будет творится ад.
Расширение адаптера будет меньше задевать другой код, и вероятность, чтот сломать. Ну это очевидный + абстракий, уменшить связность.

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

Может быть это и была ваша ситуация и вы все сделали верно ))

Parcellable просто легковеснее и быстрее, чем Serializable
А вот с точки зрения написания юнит тестов, НЯП, он геморнее и неудобнее

Мы используем parcelable на уровне ui - на view в терминах mvp. Т.е. в слое который не нужно тестировать. Оно там живёт и никого не трогает :)) Ниже не лезет

Эм, ну я привык к классификации дяди Боба ) У него верх - там где меньше деталей, и больше абстрактного.
а вью, БД, сеть - самый нижний, потому что максимум деталей и специфики платформы...

Просто переверни картинку