Я вот последная время воовсе не создаю класс интерактор)

Так как даже методы иногда могут быть юзкейсами.

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

Метод Контроллера обычно сам юзкейс

И у метода есть своя логика внутри . Это тоже рассматривается как ЮзКейс. Вот я уже избагаю оверинжениринга. Видмо я уже стар)

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

У них классный слой есть. JPA. Ой больно мне это нравтся.. У них такие худые контроллеры. Есть сервисы.(У нас тоже как бы контроллер можно сказать Активити. это тупо клей с вию и логикой. Логика можно сказать это презентер(У сприенгеров это Сервис слой). А дальше Дао классы (Это Spring Data мощнааая штука нравится мне это, думаю написать такую же для андроида) и дальше ОРМ(Хайбернет) и управление с энтити.

А у меня кстати сначала по горизонтальным слоям (ui, business, data, dagger, utils), а потом по вертикальным(конкретные фичи- auth, payments, operations...)
Data уровень чуть по другому)

JPA нуно как надо внедрить в Ведро.

Был бы нормальный стандарт. люди не бегали бы за свои реализации для стандартных решении(это ИМХО 80% аппа)

Аналогично) очень удобно юзать гибридный вариант.

Гибко!

Всем привет. Подскажите, как вы решаете такую проблему:
Есть интерактор. У него торчат Observable. Если пихнуть в onError ошибку, которую необходимо показать на ui, то придётся пересоздавать Observable. Как такой проблемы избежать?
Я пока что придумал лишь держать в базовом интеракторе отдельный Observable для ошибок и в базовом презентере подписываться и переопределять метод их обработки в дочерних презентерах.

@BigBeka да, на самом деле, не очень. Неудобно, когда у тебя ui и business разнесены по совершенно разным пакетам, хотя почти во всех примерах по android-архитектуре оно так. Вроде в большой джаве всё же советуют разбивать по фичам http://www.javapractices.com/topic/TopicAction.do?Id=205

Толстой кстати неплохие темы находит для канала своего

Каким объектно-ориентированным подходом можно заменить классы, обладающие поведением, но не имеющие состояния (хэлперы, utils, называйте их как хотите).
http://www.yegor256.com/2014/05/05/oop-alternative-to-utility-classes.html

#oop #patterns

Кстати хороший канал. Вот когда будет время потрачу месяц и прочту 2-3 книжки оттуда.

Враппер, где будет модель и ошибка

Но враппер поломает возможность дальнейшей трансформации Observable

В rx error - это то, что не дает потоку данных продолжаться, а в твоем кейсе, как я понял, ошибка - это один из типов данных. Можно для интерактора сделать модель с флагом ошибки. В презентере обрабатывать эту модели и а) мапить ее во вью модель, б) дергать метод showError() вьюхи