THEORETICAL AND METHODOLOGICAL FOUNDATIONS OF A COMPARATIVE TAXONOMY OF CLIENT APPLICATION ARCHITECTURES AND EVALUATION OF A MODULAR VERTICAL MVVM CONFIGURATION

УДК 004.41

Аннотация

Цель работы состоит в систематизации архитектур клиентских приложений и проверке применимости модульно-вертикальной конфигурации MVVM (Model-View-ViewModel) для продуктов с частыми независимыми изменениями функций. Методика объединяет концептуальный анализ официальной документации и научных публикаций, графовое представление зависимостей, порядковую оценку восьми архитектурных семейств по семи критериям и анализ чувствительности взвешенного индекса. При исходных весах модульно-вертикальная MVVM получила 4,33 балла, микрофронтенды — 3,89, Clean Architecture и FSD — по 3,70; при равных весах значения составили соответственно 4,29, 3,71 и 3,57. В 100 000 сценариев изменения весов и при переборе 128 граничных сочетаний положение модульной MVVM не изменилось, а минимальный расчётный отрыв составил 0,24 балла. Эти результаты подтверждают устойчивость ранжирования только внутри принятой оценочной матрицы и не доказывают объективного превосходства MVVM над всеми архитектурами. Иллюстративный кейс подтвердил техническую реализуемость модели и возможность контроля сформулированных инвариантов. Ограничениями являются авторский характер баллов, один рассматриваемый проект, отсутствие контрольной реализации и стандартизированного протокола консультаций. Практическая значимость работы состоит в наборе проверяемых правил модульных границ и метрик для последующей репозиторной проверки.

Abstract

The study aims to systematize client application architectures and assess the applicability of a modular vertical MVVM (Model-View-ViewModel) configuration to products with frequent independent feature changes. The method combines a conceptual review of official documentation and research publications, a graph representation of dependencies, an ordinal comparison of eight architectural families by seven criteria, and a sensitivity analysis of the weighted index. Modular vertical MVVM scored 4.33, micro-frontends 3.89, and Clean Architecture and FSD 3.70 each; with equal weights, the respective scores were 4.29, 3.71, and 3.57. Modular MVVM retained its position in 100,000 weight-variation scenarios and 128 boundary combinations; the minimum calculated gap was 0.24. These results establish stability only within the adopted assessment matrix and do not prove that MVVM is objectively superior to every architecture. The illustrative case confirmed the model’s technical feasibility and the possibility of enforcing its stated invariants. The study is limited by author-assigned scores, a single project, the absence of a control implementation, and a non-standardized consultation protocol. Its practical value lies in a set of enforceable module-boundary rules and metrics for subsequent repository-based validation.

Ключевые слова: архитектура программного обеспечения; клиентское приложение; React Native; модульность; когезия; связанность; MVVM; FSD.

Keywords: software architecture; client application; React Native; modularity; cohesion; coupling; MVVM; FSD.

Введение

Клиентское приложение объединяет интерфейс, навигацию, сетевой обмен, локальное состояние, аналитику и платформенные адаптеры. По мере роста продукта изменение одного пользовательского сценария начинает затрагивать несколько частей системы. Архитектура в этих условиях определяет не расположение файлов само по себе, а объём кода, который требуется изучить, изменить и согласовать.

Официальная документация React объясняет компонентную декомпозицию интерфейса и представление приложения в виде дерева [14, 15], но намеренно не устанавливает структуру всего проекта. Без дополнительных правил появляются общие каталоги components, hooks, services, stores и utils. Отдельные элементы остаются понятными, однако реализация одной функции распределяется между каталогами, а фактические зависимости становятся труднее прослеживать. Несоответствие таких зависимостей заявленной структуре рассматривается как архитектурная эрозия [10]. Она связана с накоплением технического долга и снижением предсказуемости изменений [4].

Цель исследования заключается в построении общей таксономии архитектур клиентских приложений и определении условий, при которых модульно-вертикальная конфигурация MVVM обеспечивает меньшую область изменения. Новизна работы заключается в единой схеме, соединяющей таксономию, взвешенную оценку и проверяемые инварианты модульной MVVM. Рабочая гипотеза состоит в том, что совпадение границы модуля с границей продуктовой функции уменьшает число элементов и межмодульных контрактов, которые требуется анализировать при её изменении. Предметом работы являются прежде всего React- и React Native-проекты, но критерии относятся к структуре модулей и потому применимы к другим клиентским технологиям.

Материалы и методы

Исследование выполнено как концептуальный сравнительный анализ официальных спецификаций, документации и научных работ, представленных на arXiv. Кодовая база описывается ориентированным графом G = (V, E), где V содержит архитектурные единицы, а E — зависимости между ними. Архитектурный подход задаёт способ формирования V и ограничения на E. Для сравнения используются семь критериев: ясность декомпозиции, внутримодульная когезия, низкая межмодульная связанность, масштабируемость, эволюционная устойчивость, управляемость сложности и стоимость освоения.

Каждый подход оценивается по порядковой шкале от 1 до 5. Один балл означает, что архитектурная граница явно не определена; два — что она поддерживается локальным соглашением; три — что правило задокументировано для всего проекта; четыре — что правило можно проверить инструментально, хотя допускаются исключения; пять — что граница автоматически контролируется и совпадает с единицей продуктового изменения.

Итоговый индекс представляет собой взвешенную сумму:

 ,                       (1)

где  — интегральная оценка подхода a;  — вес критерия k;  — балл подхода a по критерию k. Веса критериев равны соответственно 0,17; 0,16; 0,18; 0,14; 0,14; 0,12 и 0,09. Они отражают сценарий единого продукта с частыми независимыми изменениями и не являются экспертным консенсусом. Показатели модульности и понимаемости кода служат основой для последующей репозиторной проверки [5, 13].

Весовые коэффициенты критериев были определены авторами исследования на основе анализа особенностей разработки клиентских приложений, сформулированной рабочей гипотезы и практического опыта проектирования архитектуры мобильных приложений. При выборе весов учитывалась предполагаемая значимость каждого критерия для проектов, характеризующихся частыми независимыми изменениями функциональности. Выбранные значения являются частью предложенной авторами исследовательской модели и не претендуют на универсальность. Для оценки влияния субъективности выбора весов дополнительно выполнен анализ чувствительности результатов.

Таксономия отвечает на три вопроса: какая единица образует систему, как ограничиваются зависимости и какая часть может поставляться независимо. Семейства не исключают друг друга. MVVM может использоваться внутри предметного модуля, а Clean Architecture — внутри независимо поставляемой части.

Таблица 1. Таксономия архитектурных семейств

Таблица 1 не задаёт линейную шкалу зрелости и не предполагает, что одно семейство обязано заменить остальные. Столбец «Единица» показывает, вокруг какого элемента строится декомпозиция; столбец «Контроль» фиксирует механизм соблюдения границ; последний столбец связывает архитектуру с условиями, в которых её дополнительные правила окупаются. Например, независимая поставка делает микрофронтенды рациональными для нескольких автономных команд, но не даёт сопоставимого выигрыша мобильному продукту, выпускаемому единым пакетом. Такое прочтение отделяет соответствие контексту от абстрактного рейтинга популярности.

Результаты и обсуждение

Компонентная модель эффективна для построения интерфейса, но компонент слишком узок для сценария, включающего данные и бизнес-правила. Технические слои просты в начале проекта, однако распределяют функцию по каталогам. MVC, MVP и MVVM разделяют данные, представление и сценарную логику, а Flux, Redux и MVI задают однонаправленный поток состояния [12, 16]; при этом границы между функциями остаются внешней задачей. Атомарный дизайн упорядочивает уровни UI-композиции и особенно полезен для дизайн-систем [9]. Clean и Hexagonal Architecture защищают доменную логику инверсией зависимостей, но требуют дополнительных контрактов [11].

Feature-Sliced Design объединяет слои, предметные слайсы и публичные API [7, 8]. Проверяемые правила импортов полезны в крупном продукте, однако классификация между app, pages, widgets, features, entities и shared увеличивает число решений, которые команда должна согласовывать. Микрофронтенды дают командам независимую поставку, но требуют интеграции версий и общих зависимостей; в исследованиях описаны как преимущества, так и характерные антипаттерны [2, 17]. Для мобильного приложения, выпускаемого единым пакетом, эта организационная цена обычно не компенсируется независимым релизом частей.

Под MVVM (Model-View-ViewModel) в настоящей работе понимается модульно-вертикальная конфигурация. Её единицей является законченная продуктовая функция. Модуль совместно размещает интерфейс, состояние, правила, доступ к данным и тесты, поскольку эти элементы изменяются по одной причине. Внутри применено разделение model, viewModel и view [12]. Внешний доступ разрешён только через index.ts; глубокие импорты и циклы запрещены. Каталог core содержит лишь нейтральную инфраструктуру с несколькими независимыми потребителями. Тем самым модульная организация определяет предметную границу, а MVVM — роли внутри неё.

Следует различать классический шаблон MVVM и рассматриваемую модульно-вертикальную конфигурацию MVVM. В первом случае Model, ViewModel и View обычно разделяют роли внутри отдельного экрана или сценария, но сами по себе не устанавливают границы между продуктовыми функциями. Во втором случае та же тройка ролей помещается внутрь автономного функционального модуля, который владеет состоянием, данными и публичным контрактом. Поэтому в оценочной матрице базовое семейство шаблонов представления и модульная конфигурация MVVM рассматриваются раздельно: сравнивается не название шаблона, а масштаб и проверяемость архитектурной границы.

Для воспроизводимой проверки модульно-вертикальной MVVM единицей наблюдения должна быть завершённая задача изменения, а не отдельный коммит или файл. До начала работы фиксируются затрагиваемая продуктовая функция, предполагаемые контракты и исходная оценка трудоёмкости; после завершения — число изменённых модулей, доля глубоких импортов, длительность ревью, возвраты задачи и связанные регрессии. Сопоставление с базовым применением MVVM корректно только для задач сопоставимого размера и при одинаковых требованиях к тестированию. Такой протокол позволяет отделить эффект функциональной границы от квалификации разработчика, размера команды и зрелости инструментов. Он также переводит обсуждение MVVM из области предпочтений по размещению файлов в область проверяемых характеристик архитектурной изменяемости.

Рисунок 1. Архитектурная структура мобильного приложения

Иллюстративный кейс построен на мобильном приложении интеллектуального стилиста, архитектура которого зафиксирована во внутреннем описании [1]. Expo Router отвечает за маршруты [6], но не содержит бизнес-правил. На функциональном уровне выделены модули Auth, Clothing, FitChecks, Collections, Dimensions, Avatar, Quiz, Camera, Weather, Notifications и другие. Каждый из них отвечает за самостоятельную продуктовую возможность. Экраны соединяют функции, не присваивая их логику. Серверные сущности остаются в нормализованном кэше Apollo Client, а временное состояние сценария принадлежит локальному store модуля [3]. Типы GraphQL-операций формируются по серверному контракту [18]. Поэтому выбранные библиотеки выполняют разные роли и не подменяют архитектурную границу.

Предварительные профессиональные консультации проведены с техническими руководителями команд мобильной разработки и соответствующими опытными архитекторами программного обеспечения, работавшими с крупными проектами на React Native. Руководители команд описали ряд повторяющихся ситуаций.

Например, при применении FSD, отмечалось, что с ростом кодовой базы локализация изменений требовала повторного согласования между features, entities и widgets, а сквозные сценарии порождали исключения из исходных правил. В результате часть ревью уходила на обсуждение размещения кода и допустимых импортов, адаптация новых участников проекта (новых инженеров-программистов) заметно замедлялась, а отдельные задачи переносились за пределы запланированного спринта (итерации разработки). Или вот другой пример без единой архитектурной схемы, где компоненты, хуки, сервисы и хранилища были распределены по общим техническим каталогам. Возникавшие глубокие импорты, дублирование состояния и скрытые зависимости усложняли поиск дефектов; фактическая область изменения обнаруживалась уже после начала работы, поэтому первоначальные оценки сроков неоднократно пересматривались. Эти качественные наблюдения полностью подтверждают практическую значимость проблемы, но не включены в расчет индекса. Без стандартизированной анкеты, журналов задач, истории Git и контрольных реализаций причинная связь между архитектурой и задержками не может считаться доказанной.

Рисунок 2. Матрица критериев и интегральная оценка

При заданных весах компонентная модель получила 1,77 балла, технические слои — 2,52, семейство MVC, MVP и базовой MVVM — 2,82, атомарная UI-модель — 2,68, Clean Architecture и FSD — по 3,70, микрофронтенды — 3,89, модульная MVVM — 4,33. Результат модульной MVVM обусловлен совместным размещением элементов одной функции, контролируемым публичным контрактом и меньшим числом обязательных категорий. При равных весах модульная MVVM получила 4,29 балла, микрофронтенды — 3,71, Clean Architecture и FSD — по 3,57. Исключение любого одного критерия не изменило первое место. В 100 000 сценариев равномерного изменения каждого веса в пределах 25 процентов модульная MVVM всегда сохраняла первое место. Перебор 128 граничных сочетаний после нормировки весов дал минимальный отрыв 0,24 балла. Следовательно, ранжирование устойчиво только внутри принятой оценочной матрицы. Устойчивость вычисления не устраняет субъективность исходных баллов и не доказывает объективного превосходства MVVM над всеми архитектурными подходами.

Проверяемыми инвариантами модульной MVVM являются импорт только через index.ts, отсутствие циклов, локализация бизнес-логики в функциональном модуле, нейтральность core и единственность источника истины. Их можно контролировать правилами ESLint, анализом графа импортов и архитектурными тестами. Практический эффект следует измерять по медианному времени однотипной задачи, числу изменённых файлов и модулей, продолжительности ревью, межмодульным регрессиям и времени до первой самостоятельной правки нового участника. Показатели необходимо нормировать по размеру изменения, опыту исполнителя и тестовому покрытию.

Модульная MVVM локализует инженерную работу, но непосредственно не ускоряет исполнение приложения: производительность определяется состоянием, обновлениями, кэшированием и нативными адаптерами. Исследование ограничено авторскими баллами, одним проектом, отсутствием контрольной реализации и неполным протоколом консультаций.

Интерпретация результатов требует разграничения угроз валидности. Конструктная валидность ограничена тем, что порядковые баллы сводят неоднородные свойства архитектуры к единому индексу; близкие итоговые значения поэтому нельзя трактовать как точное измерение трудоёмкости. Внутренняя валидность ограничена отсутствием контрольной реализации: сокращение области изменения может быть связано не только с модульной MVVM, но и с опытом команды, качеством тестов или стабильностью требований. Внешняя валидность ограничена одним мобильным приложением и не позволяет без проверки переносить результат на настольные, веб- и встроенные клиентские системы. Наконец, выводы консультаций подвержены ошибке ретроспективной оценки и потому используются лишь как контекст, а не как количественное подтверждение.

Для последующего исследования предлагается квазиэкспериментальный дизайн: выбрать сопоставимые функции в нескольких репозиториях, зафиксировать их исходный граф зависимостей, затем измерить одинаковые типы изменений до и после введения публичных контрактов модулей. Основными показателями должны служить медианное число затронутых модулей, доля межмодульных импортов, время ревью и частота регрессий; доверительные интервалы и непараметрические тесты позволят оценить, превышает ли наблюдаемый эффект естественную вариативность задач. Такой дизайн проверяет именно модульно-вертикальную конфигурацию MVVM, не приписывая базовому шаблону представления свойства всей архитектуры проекта.

Заключение

Поставленная цель достигнута в пределах концептуального исследования. Построенная таксономия различает архитектуры по основной единице, контролю зависимостей и модели поставки. Сравнение показало, что рассмотренные подходы решают разные задачи и не должны оцениваться вне контекста продукта и организации команды.

Для продукта с частыми независимыми изменениями расчетная модель поддерживает рабочую гипотезу о модульной MVVM. Совпадение функциональной границы, публичного контракта и ответственности команды уменьшает потенциальную область анализа изменения. Иллюстративный кейс подтвердил техническую реализуемость модели и возможность контроля сформулированных инвариантов. Анализ чувствительности подтвердил устойчивость ранжирования внутри принятой оценочной матрицы, но не объективное превосходство MVVM над всеми архитектурами.

Технические руководители предварительных профессиональных консультаций также выразили готовность применять модульно-вертикальную MVVM в новых проектах и рассматривать поэтапный переход к ней в существующих системах при наличии измеримых критериев эффективности.

В дальнейшем планируется проверить предложенную архитектурную модель на нескольких проектах, разработанных с использованием React и React Native. Для этого следует сравнить время реализации однотипных задач, количество изменяемых модулей, продолжительность поиска дефектов и длительность проверки кода. До получения таких данных модульно-вертикальную MVVM целесообразно применять в отдельных функциональных модулях и оценивать её эффективность по указанным показателям.

Список литературы:

1. Панюшкин А. М., Слесарев Р. А. Архитектурное описание мобильного приложения интеллектуального стилиста. Внутренний технический документ. 2026.
2. Antunes F., Lima C., Araújo A., Taibi D., Kalinowski M. Investigating Benefits and Limitations of Migrating to a Micro-Frontends Architecture // Proceedings of the XXXVIII Brazilian Symposium on Software Engineering (SBES 2024). SBC, 2024. P. 103–113. DOI: 10.5753/sbes.2024.3303.
3. Apollo GraphQL. Configuring the Apollo Client Cache [Электронный ресурс]. URL: https://www.apollographql.com/docs/react/caching/cache-configuration (дата обращения: 09.07.2026).
4. Behutiye W. N., Rodriguez P., Oivo M., Tosun A. Analyzing the Concept of Technical Debt in the Context of Agile Software Development // arXiv. 2024. arXiv:2401.14882.
5. Emanuel A. W. R., Wardoyo R., Istiyanto J. E., Mustofa K. Modularity Index Metrics for Java-Based Open Source Software Projects // arXiv. 2013. arXiv:1309.5689.
6. Expo. Introduction to Expo Router [Электронный ресурс]. URL: https://docs.expo.dev/router/introduction/ (дата обращения: 12.05.2026).
7. Feature-Sliced Design. Overview. Version 2.1 [Электронный ресурс]. URL: https://feature-sliced.design/docs/get-started/overview (дата обращения: 31.05.2026).
8. Feature-Sliced Design. Public API [Электронный ресурс]. URL: https://feature-sliced.design/docs/reference/public-api (дата обращения: 11.07.2026).
9. Frost B. Atomic Design [Электронный ресурс]. URL: https://atomicdesign.bradfrost.com/ (дата обращения: 29.06.2026).
10. Li R., Liang P., Soliman M., Avgeriou P. Understanding Software Architecture Erosion: A Systematic Mapping Study // Journal of Software: Evolution and Process. 2022. Vol. 34, No. 3. e2423. DOI: 10.1002/smr.2423.
11. Microsoft. Common Web Application Architectures. Clean Architecture [Электронный ресурс]. URL: https://learn.microsoft.com/en-us/dotnet/architecture/modern-web-apps-azure/common-web-application-architectures (дата обращения: 11.06.2026).
12. Microsoft. Model-View-ViewModel [Электронный ресурс]. URL: https://learn.microsoft.com/en-us/dotnet/architecture/maui/mvvm (дата обращения: 07.06.2026).
13. Muñoz Barón M., Wyrich M., Wagner S. An Empirical Validation of Cognitive Complexity as a Measure of Source Code Understandability // Proceedings of the 14th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM 2020). ACM, 2020. P. 5:1–5:12. DOI: 10.1145/3382494.3410636.
14. React. Thinking in React [Электронный ресурс]. URL: https://react.dev/learn/thinking-in-react (дата обращения: 02.05.2026).
15. React. Understanding Your UI as a Tree [Электронный ресурс]. URL: https://react.dev/learn/understanding-your-ui-as-a-tree (дата обращения: 04.05.2026).
16. Redux. Style Guide [Электронный ресурс]. URL: https://redux.js.org/style-guide/ (дата обращения: 05.07.2026).
17. Silva N. P. S., Rodrigues E., Conte T. A Catalog of Micro Frontends Anti-patterns // Proceedings of the 47th IEEE/ACM International Conference on Software Engineering (ICSE 2025). IEEE, 2025. P. 2151–2162. DOI: 10.1109/ICSE55347.2025.00079.
18. The Guild. Introduction to GraphQL Code Generator [Электронный ресурс]. URL: https://the-guild.dev/graphql/codegen/docs/getting-started (дата обращения: 22.06.2026).

References

1. Panyushkin A. M., Slesarev R. A. Architectural Description of an Intelligent Stylist Mobile Application. Internal technical document. 2026. (In Russ.).
2. Antunes F., Lima C., Araújo A., Taibi D., Kalinowski M. Investigating Benefits and Limitations of Migrating to a Micro-Frontends Architecture. Proceedings of the XXXVIII Brazilian Symposium on Software Engineering (SBES 2024). SBC, 2024. P. 103–113. DOI: 10.5753/sbes.2024.3303.
3. Apollo GraphQL. Configuring the Apollo Client Cache. Available at: https://www.apollographql.com/docs/react/caching/cache-configuration (accessed: 09.07.2026).
4. Behutiye W. N., Rodriguez P., Oivo M., Tosun A. Analyzing the Concept of Technical Debt in the Context of Agile Software Development. arXiv. 2024. arXiv:2401.14882.
5. Emanuel A. W. R., Wardoyo R., Istiyanto J. E., Mustofa K. Modularity Index Metrics for Java-Based Open Source Software Projects. arXiv. 2013. arXiv:1309.5689.
6. Expo. Introduction to Expo Router. Available at: https://docs.expo.dev/router/introduction/ (accessed: 12.05.2026).
7. Feature-Sliced Design. Overview. Version 2.1. Available at: https://feature-sliced.design/docs/get-started/overview (accessed: 31.05.2026).
8. Feature-Sliced Design. Public API. Available at: https://feature-sliced.design/docs/reference/public-api (accessed: 11.07.2026).
9. Frost B. Atomic Design. Available at: https://atomicdesign.bradfrost.com/ (accessed: 29.06.2026).
10. Li R., Liang P., Soliman M., Avgeriou P. Understanding Software Architecture Erosion: A Systematic Mapping Study. Journal of Software: Evolution and Process. 2022. Vol. 34, No. 3. e2423. DOI: 10.1002/smr.2423.
11. Microsoft. Common Web Application Architectures. Clean Architecture. Available at: https://learn.microsoft.com/en-us/dotnet/architecture/modern-web-apps-azure/common-web-application-architectures (accessed: 11.06.2026).
12. Microsoft. Model-View-ViewModel. Available at: https://learn.microsoft.com/en-us/dotnet/architecture/maui/mvvm (accessed: 07.06.2026).
13. Muñoz Barón M., Wyrich M., Wagner S. An Empirical Validation of Cognitive Complexity as a Measure of Source Code Understandability. Proceedings of the 14th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM 2020). ACM, 2020. P. 5:1–5:12. DOI: 10.1145/3382494.3410636.
14. React. Thinking in React. Available at: https://react.dev/learn/thinking-in-react (accessed: 02.05.2026).
15. React. Understanding Your UI as a Tree. Available at: https://react.dev/learn/understanding-your-ui-as-a-tree (accessed: 04.05.2026).
16. Redux. Style Guide. Available at: https://redux.js.org/style-guide/ (accessed: 05.07.2026).
17. Silva N. P. S., Rodrigues E., Conte T. A Catalog of Micro Frontends Anti-patterns. Proceedings of the 47th IEEE/ACM International Conference on Software Engineering (ICSE 2025). IEEE, 2025. P. 2151–2162. DOI: 10.1109/ICSE55347.2025.00079.
18. The Guild. Introduction to GraphQL Code Generator. Available at: https://the-guild.dev/graphql/codegen/docs/getting-started (accessed: 22.06.2026).