Например в группе приложений одного и того же производства можно

сделать одинаковую регистрацию/авторизацию. Но при этом после ее прохождения она будет отправлять на разные экраны

приложение магазина для продавца и покупателя после авторизации будет вести на товары/личный кабинет (делать 2 разных навигации?)

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

можно. Все можно. Только это принесет свои последствия. например нельзя модуль будет перенести в другое приложение (т.е. отсутствие гибкости) а это влечет за собой кратное увеличение правок (нарушение DRY), вместо того, чтобы 1 раз изменить navigator - меняем в каждом продукте

Гораздо более гибкое решение после авторизации вызвать abstractRouter.forward(), чем переписывать эти реализации каждый раз

вам так или иначе придётся что-то переписывать, если у вас в разных вариациях вашего приложения будет разная навигация

разумеется. Только если 3 меня 3 продукта - мне придется переписать 1 абстракцию и 3 реализации; при Вашем решении 3 абстракции и 3 реализации

при моём решении тоже будет 1 абстракция и 3 реализации

верно. Я затупил

в Вашем решении бизнес слой будет привязан к навигации. И если его перенести в приложение, где навигация будет не нужна - будет болтаться лишние классы

не, ну если это приложение "Hello world", то действительно на некоторых платформах может не потребоваться навигация

В доменном слое должны быть исключительно 3 вещи: usecase'ы, business entity, интерфейсы источников данных. Навигация - это чисто ui.

там еще могут быть AbstractPresentation(опционально) я разделяю ui и presentation

А что такое в вашем понимании AbstractPresentation?

абстракция Presenter/ViewModel Как например отображать новое сообщение в чате, если Domain ничего не знает про Presentation?

Презентер подписывается на usecase к примеру через callback/rx observer

т.е. presenter обращается к domain. Я говорю про случай, когда с бекенда приходит push. Как Domain'у обратиться к Presenter'у?

Ну к примеру частный случай: через rx flowable отлично реализуется такая модель. Посмотрите к примеру как можно получать уведомления об измении бд через room + rx

нет ни rx ни flowable (бизнес запрещает)

Ну используйте обычные колбэки, какая разница)

как domain'у вызвать метод у presenter'а если он ничего о нем не знает?

Домайн не должен вызывать методы у презентера, это прямое нарушение принципов solid

да ладно?

т.е. вызовы у абстрактных источников данных - не нарушение, а вызов у абстрактного пресентера - нарушение. Что-то не складывается

Какой же тут принцип солида нарушается ?

Вызов источников данных которые реализуют интерфейсы источников данных обозначенных в доменном слое это не нарушение

так разница в чем?

я Вам больше скажу, в Domain'е еще много интерфейсов лежит (как минимум 2 еще)

Сугубо индивидуально, чистая архитектура это абстракция, которая не ставит нас в жесткие рамки

Инверсия зависимостей очевидно

и где идет нарушение?

Так это нарушение чистой архитектуры, а не солида

Насколько я помню инверсия зависимостей это как раз последний из принципов в аббревиатуре solid, чистая архитектура базируется на нём

мимо. Чистая архитектура реализует все 5 принципов

Это циклическая зависимость получается, не?

Да, все 5 принципов, я и не утвеждал обратное

Jorik Fat
вот тут нет циклической зависимости?

Так твоя база не знает об интеракторах