Но если вернуться к сути вопроса в контексте конкретно архитектуры - тогда врятли.
Ну смотрите. Мы пишем магазин. Есть склад с товарами и несколько прилавков. На уровне проектирования нам нужно решить, каким образом компоненты нашего магазина будут взаимодействовать. Продавец может бегать на склад с запросом на товар по некоему триггеру. В нашем случае - покупатель пожаловал-с. Или же кладовщик может пинать продавцов каждый раз, когда состояние товаров на складе меняется(что-либо продали, или завезли). Граммотная архитектура позволит мне легко заменить склад на какой-нибудь альтернативный, или прилавок. Но вот переход от принятого по всей системе стиля общения между модулями не получится провести без существенных изменений всех модулей.
Ваше замечание вполне правомерно. Завязываясь на ReactiveX, мы не сможем в последствии безболезненно от него отказаться. Но это неизбежно, т.к. ркс не является либой, решающей некую конкретную задачу. Это набор инструментов для организации глобальной парадигмы и его замена будет чуть не равносильна отказу от ООП. И ваше замечание, как мне думается, равносильно замечанию: "а что , если мы вдруг захотим перейти на Flatter"? Ну тогда лично мне придется переписать приложение. Т.К. я не знаю архитектурного подхода, позволяющего превратить такие фундаментальные изменения в штатный случай.
я могу рассказать, как такое заимплементить без завязки на рхджаву, но тогда мне придётся рассказать, что такое HKT, а затем фри-монада или теглесс файнал
Как раз тот случай, когда зависеть от стабильной и работающей штуки не так уж плохо. Главное четко понимать, к чему это приведет, и если вы абсолютно уверены, что не перейдете на МПП - не надо под него затачиваться. Нет сферической архитекруты в вакууме, есть та, которая решает конкретную задачу и оставляет некоторую гибкость в тех рамках, которые вам нужны.
Обсуждают сегодня