Сравнительный анализ

Традиционные MV*-архитектуры (MVC, MPV, MVVM и т.п.) объединяет общее свойство: они описывают один экран либо группу экранов, т.е. взаимодействие сущностей между элементами одного модуля. MV*-архитектуры не затрагивают вопросы межмодульного взаимодействия, такие как:

• кто инстанцирует модуль и запускает его на выполнение?
• куда передается поток управления от модуля, завершившего работу?
• кто отвечает за обработку общих для всех модулей ошибок?
• кто обслуживает обработку deeplinks (т.е. переход в произвольную часть навигации)?
• кто отвечает за процесс логаута (очистку кеша, завершение фоновых процессов)?

Традиционно подобные задачи ложатся на плечи какого-нибудь координатора, в итоге мы получаем «MVVM c координаторами» или «VIPER с шиной данных». Что именно кроется под выбранным словосочетаниям известно только команде разработчиков, которая его выбрала, потому что в конечном итоге решение неминуемо модифицируется под возможности и потребности конкретной команды.

Ключевая задача ROSS состоит в том, чтобы перейти от «перекладывания ответственностями между буковками» в рамках одного модуля к описанию UserFlow целиком. Подобную задачу призваны решить UDF-архитектуры, но их ключевое преимущество в виде единого State является же и ахиллесовой пятой. Единый State не масштабируется: начинаются сложности с синхронизацией различных кешей, игнорируется наличие UI-state (анимации, например), невозможно откатить цепочку изменений в рамках неудачного сценария.

Ключевые особенности ROSS:

• полная инкапсуляция UI-слоя, разделение UI-логики и бизнес-логики;
• прямое отображение UserFlow в программную сущность (сценарий);
• state приложения распределен между совокупностью независимых сервисов.