читай книжку про рх, которую выше кидали =)

@eugene_matsyuk Здесь уже кажется обсуждали ваши архитектурные решения, но я хотел дополнительно задать вам вопрос.
В большинстве литературы и опенсорсах трехуровневая архитектрура (слой пользовательского интерфейса (представления), слой бизнес-логики, слой доступа к данным) представлена следующей схемой зависимостей: слой пользовательского интефейса зависит от слоя бизнес - логики, слой доступа к данным зависит от слоя бизнес-логики, бизнес-логика не зависит ни от одного слоя (presentation -> domain <- data). Если говорить об андроиде, то слой пользовательского интерфейса (представления) будет знать о всех слоях, которые есть в приложении, так как в этом слое происходит связываение всех зависимостей в приложении.

Профит от такого подхода, конечно в реалиях, это возможно будет не настолько просто, но усилий нужно приложить меньше, чем при других подходах:

1. Можем заменить пользовательский интерфейс не затронув другие слои
2. Можем заменить библоиотеку доступа к данным не затронув другие слои
3. Бизнес-логика является ядром приложения и без лишних зависимостей может быть перенесена куда угодно, другое приложение, другая платформа и т.д.

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

В итоге схема зависимостей у вас примерно такая presentation <--> domain -> data. Что теоретически лишает вас некоторых вышеперечисленных профитов.

Расскажите о том, что послужило поводом для такого решения, какие преимущества у вашего подхода и почему не используете вышеупомянутую схему зависимостей? Должен признаться, пока ни одним из профитов архитектуры, которые перечислил не приходилось воспользоваться, но это стандартное решение.

Есть пара вопросов по архитектуре. Влился в чатик после последнего dev подкаста и возможно вопросы обсуждались и я их пропустил.
1. https://github.com/grandstaish/hello-mvp-dagger-2 может кто-то использовал похожую архитектуру MVP, domain, interactor etc. Она в примере больше заточена под rx и хранение Subject, которое происходит в Interactor, а Presenter (пере-)подписывается на него. Я таким образом решил проблему переворота экрана и переподски на длительные сетевые операции, но ссылку на Subject пока храню в Presenter.
2. В недалеком будущем предстоит рефакторинг большого проекта с довольно сложной навигацией (стек в стеке, перепрыгивания в стеках через несколько шагов как вперед так и назад). Кто-нибудь использовал conductor (https://github.com/bluelinelabs/Conductor) или вместе в связке с Mosby (https://github.com/sockeqwe/mosby)?

Итак, по поводу интерактора. В принципе я согласен с тем, что он должен просто возвращать свою бизнесовую модельку в презентер, а презентер пускай сам там мапит.
Но. Еще одна модель и маппинг. Практически всегда вы не переиспользуете интерактор таким образом, чтобы подцепить его к абсолютно другой вьюшке. Максимум - вы просто делаете другую имплементацию. Да, есть интеракторы, которые могут понадобиться в нескольких местах приложения. Но обычно они просто заиспользуются другими интеракторами, которые уже работают с вьюшкой.
Проанализировав все это, я понял, что еще одни модели в принципе не нужны.
Кроме того, если мы делаем еще один модельки, то маппинг достается презентеру. А мне его стало жалко. Ну как-то преобразование моделей к UI слою не очень то по мне (а в UI слое у меня View and Presenter), но это мое субъективное ощущение. Я решил вопрос маппинга максимально делегировать интерактору. Понятное дело, Интерактор это делегирует специальному классу.
Поэтому да, я тут чуть уклонился от канонов. Но это я сделал для большего удобства и уменьшения оверхеда.
Вообще тут боль большая с этими модельками и маппингом их. Иногда это раздражает)
@xanderblinov @senneco вы вроде говорили, что у вас как-то автоматом это делается? Вообщем у кого какие идеи, как минимизировать эту боль?
@mansonheart Киньте, пожалуйста, ссылки, где сказано, что domain ничего не должен знать о других слоях. Помечу у себя.

ок, я вам соберу материал тогда и скину пачкой, в одной книге автор даже описывает процесс рефакторинга в эту сторону, немного времени нужно)

да, будет супер
сами то что думаете на счет этого?

и тогда заодно напишу свое мнение