СРАВНИТЕЛЬНЫЙ АНАЛИЗ АРХИТЕКТУРНЫХ ПОДХОДОВ В ВЕБ-РАЗРАБОТКЕ: MVC, HEXAGONAL И CLEAN ARCHITECTURE

АННОТАЦИЯ

В данной работе представлен сравнительный анализ трёх архитектурных подходов к веб-разработке: классического шаблона MVC, шестиугольной (Hexagonal) архитектуры и Clean Architecture. В качестве экспериментальной платформы использовалось единое веб-приложение, реализованное по каждому из подходов, с идентичной бизнес-логикой (CRUD-модуль). В эксперименте нагрузочные тесты (GET и POST-запросы) проводились при разном числе параллельных пользователей (20, 200, 2000) с помощью инструмента Autocannon. Результаты показывают влияние архитектуры на производительность и сопровождаемость системы, а также демонстрируют рост процента ошибок при высоком уровне параллельности для GET-запросов. Более сложные архитектуры (Hexagonal и Clean) обеспечивают лучшую модульность и тестируемость кода, но требуют от разработчиков более глубокого понимания принципов разделения ответственности и дополнительных усилий на этапе проектирования.

ABSTRACT

This paper presents a comparative analysis of three architectural approaches to web development: the classic MVC pattern, Hexagonal Architecture, and Clean Architecture. A unified web application, implementing identical business logic (a CRUD module), was used as the experimental platform for each approach. Load tests (GET and POST requests) were conducted with varying numbers of concurrent users (20, 200, 2000) using the Autocannon tool. The results reveal the impact of architecture on system performance and maintainability, as well as an increase in error rates under high concurrency levels for GET requests. More complex architectures (Hexagonal and Clean) provide better modularity and code testability but require developers to have a deeper understanding of the principles of responsibility separation and to invest additional effort during the design phase.

Ключевые слова: веб-разработка, MVC, Hexagonal Architecture, Clean Architecture, тестируемость, масштабируемость, нагрузочное тестирование.
Keywords: web development, MVC, Hexagonal Architecture, Clean Architecture, testability, scalability, load testing.

ВВЕДЕНИЕ

Современные веб-приложения вынуждены удовлетворять широкому спектру требований: высокой производительности, лёгкой модифицируемости, возможности быстрого внедрения новых функций, а также соответствия стандартам качества и безопасности. В соответствии с ISO/IEC/IEEE 29148:2011, архитектура программного обеспечения призвана способствовать эффективной разработке и дальнейшему сопровождению системы, обеспечивая при этом надежность, совместимость и гибкость.

Среди многочисленных архитектурных подходов к организации веб-приложений наиболее распространены классическое MVC [4], шестиугольная архитектура (Hexagonal Architecture) [7; 8] и Clean Architecture [1]. Каждая из них по-своему разделяет ответственность между слоями и управляет зависимостями. При этом остаётся вопрос, в какой мере выбор архитектурного паттерна влияет на производительность и сопровождаемость в реальной практике — как в небольших проектах, так и в более масштабных системах [5].

Цель данной работы — проанализировать и сравнить ключевые характеристики трёх распространённых архитектурных шаблонов (MVC, Hexagonal, Clean Architecture) применительно к веб-разработке: производительность, сопровождаемость, масштабируемость и сложность кода. Исследование основывается на едином примере веб-приложения, что позволяет провести сопоставление на практике. В итоге формулируются рекомендации по выбору архитектуры, исходя из объема проекта, требований к поддержке и планов по дальнейшему развитию системы.

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

МАТЕРИАЛЫ И МЕТОДЫ

Объект исследования

Объектом исследования выступает небольшое веб-приложение, которое для целей эксперимента реализует простой модуль функционалом просмотра и создания объектов товара, используемых в e-commerce. Код организован так, чтобы унифицировано сравнить три архитектурных подхода (MVC, Hexagonal Architecture, Clean Architecture) и оценить их влияние на производительность и сопровождаемость.

Архитектурные подходы

MVC (Model–View–Controller) - широко применяется во многих фреймворках (Symfony, Laravel, Ruby on Rails [4]). Модель хранит и обрабатывает данные (иногда вместе с бизнес-логикой), Представление (View) отвечает за формирование конечного вывода (HTML, JSON и т. д.), а Контроллер (Controller) получает запросы от клиента и координирует взаимодействие с Моделью и Представлением. В классических MVC-фреймворках нередко часть логики в силу простоты размещают в контроллерах, что при масштабировании может приводить к разрастанию кода и усложнению поддержки [4].

На Рисунке 1 представлена диаграмма взаимодействия основных компонентов в MVC. На этой схеме клиент отправляет запрос контроллеру, контроллер вызывает методы модели (управляющей бизнес-логикой и взаимодействием с базой данных), а затем передает управление представлению. Представление формирует ответ (HTML, JSON и т. д.) и возвращает его клиенту.

Рисунок 1. Схема взаимодействия компонентов в MVC

Hexagonal Architecture (Ports and Adapters) подход четко разделяет ядро приложения (Core / Domain / Application) и набор «портов» (ports), через которые ведется взаимодействие с внешним миром [7]. Порты представляют собой интерфейсы или абстракции, а адаптеры (adapters) — конкретные реализации этих интерфейсов для работы с базой данных, пользовательскими интерфейсами (UI) или внешними системами. Таким образом, бизнес-логика «не знает» о конкретном способе хранения данных или о том, как выглядит UI, поскольку все детали инкапсулированы в адаптерах.

На Рисунке 2 показана схема Ports and Adapters (Hexagonal Architecture). Центральная часть (Domain, Application) содержит бизнес-правила и сценарии использования, а входные и выходные порты (Inbound и Outbound) описаны в виде интерфейсов. Конкретные адаптеры реализуют эти интерфейсы, что позволяет легко заменять инфраструктурные решения без изменения доменной логики.

Рисунок 2. Схема Ports and Adapters (Hexagonal Architecture)

Clean Architecture подход, сформулированный Робертом Мартином (Uncle Bob) [1], ещё жёстче регламентирует слои приложения и принцип инверсии зависимостей. Слой Entities — доменные объекты (бизнес-модель), максимально абстрагированные от инфраструктуры. Use Cases (Application Layer) — сценарии использования (например, CreateOrder), которые оперируют сущностями и определяют бизнес-правила. Interface Adapters — обеспечивают переход от внешних запросов к Use Cases и обратно, а также могут содержать конкретные реализации репозиториев. Frameworks & Drivers — всё, что касается конкретных технологий (фреймворки, драйверы, базы данных), наиболее подверженных изменениям, поэтому они вынесены во внешний слой. Дополнительные исследования демонстрируют влияние Clean Architecture на улучшение тестируемости и сопровождаемости кода [2; 3].

На Рисунке 3 представлена упрощенная диаграмма Clean Architecture. Здесь зависимости направлены извне внутрь: бизнес-правила и сущности не зависят от технических деталей, а инфраструктурный слой, напротив, знает о внутренних интерфейсах и реализует их.

Рисунок 3. Структурная схема Clean Architecture

План эксперимента

На этапе подготовки были развернуты три экземпляра приложения (MVC, Hexagonal, Clean) в идентичной среде. Для эксперимента использовались следующие конфигурации и инструменты:

• ОС: Ubuntu 22.04.2 LTS (WSL2 под Windows 10/11)
• CPU: Intel(R) Core(TM) i7‑10750H @ 2.60 GHz (6 ядер / 12 потоков)
• ОЗУ: ~23 ГБ (доступно в WSL)
• Диск: SSD NVMe, чтение ~3200 МБ/с, запись ~2000 МБ/с
• Node.js: v22.12.0
• Express: 4.18.2
• Autocannon (для нагрузки).

Во всех трёх вариантах код запускается локально, обрабатывая HTTP-запросы типа GET /products и POST /products для просмотра и создания товаров соответственно. Тестовые данные в формате JSON генерируются с помощью библиотеки Faker (10 000 товаров, 1 000 пользователей) с использованием единого скрипта и применяются во всех проектах. Для нового эксперимента нагрузка создавалась с помощью инструмента Autocannon при следующих уровнях параллельности: 20, 200 и 2000. В каждом случае выполнялись следующие сценарии: многократные запросы GET /products для получения списка товаров и многократные запросы POST /products для создания товара. Каждый сценарий исполнялся в течение 10 секунд, при этом фиксировались следующие показатели: средняя латентность (в миллисекундах), пиковое время ответа (в миллисекундах) и процент ошибок (от общего числа запросов). Полученные результаты представлены ниже в Таблице 1.

Реализация и структура тестовых приложений

Для сравнения трех архитектур были написаны три небольших Node.js/Express-приложения с функциями просмотра и создания товаров. В качестве хранилища данных везде применялось простое in-memory-хранение (без реальной СУБД), чтобы исключить влияние внешних факторов и сосредоточиться на сравнении структуры кода.

1. MVC. Запросы обрабатываются в контроллере, который напрямую взаимодействует с моделью и in-memory коллекцией, а результат возвращается пользователю.
2. Hexagonal. Логика управления товарами расположена в application-слое и не зависит от способа хранения данных: используется отдельный адаптер (репозиторий) для in-memory. Компоненты Express выступают в роли входного адаптера, переводящего HTTP-запросы во внутренние вызовы.
3. Clean Architecture. Бизнес-правила вынесены в отдельные use cases, а Express-слой лишь адаптирует запросы к ним. Инфраструктурные детали (например, способ хранения) скрыты во внешнем слое, позволяя легко подменять реализацию.

РЕЗУЛЬТАТЫ И ОБСУЖДЕНИЕ

Для оценки производительности при различных уровнях параллельности (20, 200, 2000 одновременных запросов) были собраны данные по среднему и пиковому времени ответа, а также по проценту ошибок. Полученные результаты приведены в Таблице 1.

Таблица 1.

Среднее время ответа, пиковое время ответа и процент ошибок при различном числе параллельных запросов (GET и POST для MVC, Hexagonal и Clean)

Примечание: показатели взяты из конкретного локального теста; в других условиях и при иной аппаратной конфигурации они могут отличаться.

Как видно из таблицы, при нагрузке в 20 и 200 запросов все три архитектуры обрабатывают GET и POST достаточно стабильно и с невысоким временем ответа. Существенная разница проявляется при 2000 параллельных запросов, когда GET-запросы показывают рост времени ответа до 4–4,5 с и высокий процент ошибок (49–53 %), в то время как POST-запросы остаются относительно стабильными (около 250 мс и не более 2–3 % ошибок).

График зависимости времени ответа от числа параллельных запросов

Для более наглядного сравнения во всех трёх архитектурах и двух типах запросов (GET и POST) построен график (Рисунок 4). По оси X отложены значения 20, 200 и 2000 (число параллельных запросов), по оси Y — среднее время отклика (мс). На графике представлено шесть линий: для каждой архитектуры (MVC, Hexagonal, Clean) отдельно показано поведение GET- и POST-запросов.

Рисунок 4. График зависимости времени ответа от числа параллельных запросов

На графике видно, что:

1. При 20 одновременных запросах задержка при GET (около 120–130 мс) немного выше, чем при POST (3–4 мс). Из данных Таблицы 1 следует, что при такой нагрузке процент ошибок равен нулю.
2. При увеличении нагрузки до 200 запросов время ответа для GET-запросов заметно возрастает (примерно до 1000–1150 мс), тогда как POST-запросы продолжают обрабатываться быстрее (около 200 мс). Ошибок по-прежнему не зафиксировано.
3. При экстремальной параллельности (2000 запросов) все три архитектуры демонстрируют резкий рост времени ответа для GET-запросов (средние значения около 4400–4500 мс). По данным Таблицы 1, именно в этих сценариях наблюдается существенный процент ошибок (до 50 %), что объясняется большим объёмом отдаваемых данных. В то же время задержка POST-запросов остается на уровне 250–260 мс, а процент ошибок значительно ниже (не превышает 2–3 %).

Из графика следует, что при 20 и 200 запросах кривая для GET во всех архитектурах находится выше, чем для POST, однако при данных нагрузках процент ошибок остается минимальным или нулевым. При 2000 запросах все три реализации показывают резкий скачок задержек у GET и соответствующий рост ошибочных запросов (по данным Таблицы 1), тогда как POST сохраняет более скромные показатели как по времени ответа, так и по числу неуспешных запросов.

Обсуждение результатов

При низкой и средней нагрузке (20–200) разница между архитектурами несущественна, и все варианты обрабатывают запросы вполне предсказуемо. Основное отличие заключается в том, что GET несколько медленнее из-за большего объёма передаваемых данных (список товаров), а POST-запросы выполняются фактически мгновенно (3–4 мс при 20 параллельных запросах, около 200 мс при 200). Процент ошибок в этих режимах отсутствует.

При экстремальной параллельности (2000 запросов) GET-запросы становятся «узким местом» во всех трёх архитектурах, среднее время ответа превышает 4 с, а доля неудачных запросов достигает 49–53 %. Основная причина — отправка большого объёма данных одновременно в условиях ограниченных ресурсов (один экземпляр приложения, отсутствует кэширование или пагинация). Для POST ситуация лучше: задержка увеличивается лишь до 250–260 мс, а процент ошибок остается на уровне 1.7–2.1 %.

Таким образом, в режиме «экстремальной» нагрузки именно объём отдаваемых данных и масштаб параллельности приводят к тому, что GET-запросы сильнее страдают. В остальном различия между MVC, Hexagonal и Clean минимальны с точки зрения «сырой» пропускной способности, но при этом в крупном и долгоживущем проекте более формализованные архитектуры (Hexagonal, Clean) всё же предпочтительнее по ряду качественных характеристик, связанных с модульностью, тестируемостью и упрощением поддержки.

Сопровождаемость и структурные аспекты

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

С точки зрения структуры кода и долгосрочной сопровождаемости:

• MVC даёт быструю разработку для малых проектов, однако при масштабировании логика может «расползаться» по контроллерам.
• Hexagonal и Clean обеспечивают более жесткую изоляцию бизнес-правил, что упрощает тестирование и рефакторинг в крупных системах. Но на начальном этапе требуется больше усилий и дисциплины при проектировании.

ОГРАНИЧЕНИЯ ЭКСПЕРИМЕНТА

• В исследовании использован небольшой объем кода без подключения реальной СУБД, а все данные хранятся в памяти. Такой подход упрощает разработку и исключает влияние базы данных, однако в реальных проектах критическую роль играет оптимизация запросов к СУБД, работа с индексами и другие факторы, связанные с хранением данных.
• Не учитывались сетевые задержки и микросервисное окружение, хотя в распределенных системах существенную роль могут играть задержка в сети, балансировщики, очереди и проблемы частичной доступности сервисов.
• Реализована ограниченная функциональность (отсутствуют пагинация, кэширование, шардирование), что упрощает модель приложения и не отражает всех особенностей высоконагруженных систем, где подобные механизмы существенно влияют на производительность и масштабируемость.

ЗАКЛЮЧЕНИЕ

В ходе исследования были рассмотрены три подхода к построению веб-приложений: классический шаблон MVC, шестиугольная архитектура (Hexagonal Architecture) и Clean Architecture. Все три показали сравнимую производительность при невысокой нагрузке (до 20–200 параллельных запросов). Однако при экстремальной параллельности (2000 запросов) наиболее отчётливо проявилось влияние объёма передаваемых данных (особенно в GET /products), приводя к росту времени ответа и повышенному проценту ошибок.

MVC обеспечивает быстрый старт разработки и простую структуру кода в небольших проектах, но со временем может усложняться из-за смещения логики в контроллеры. Hexagonal Architecture чётко разделяет бизнес-логику и внешние адаптеры, что повышает гибкость и тестопригодность. Clean Architecture ещё жёстче разграничивает слои и реализует принцип инверсии зависимостей, помогая достичь независимости бизнес-логики от инфраструктуры, однако требует более глубокого понимания архитектурных принципов и аккуратного планирования.

С точки зрения выбора архитектуры для реальных веб-систем, небольшие и срочные проекты могут эффективно использовать MVC ради упрощения и скорости разработки, тогда как крупные и долговременные проекты выигрывают от более строго структурированных решений (Hexagonal или Clean Architecture), где важна надежная база для масштабирования и изменения бизнес-требований.

В перспективе данное исследование можно расширять путем подключения реальной СУБД (SQL, NoSQL), имитации микросервисных взаимодействий, учёта сетевых задержек и распределенных сред, а также внедрения механизмов кэширования и пагинации. Такие шаги позволят получить ещё более полную картину влияния архитектурных паттернов на работу высоконагруженных и комплексных веб-приложений.

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

1. Мартин, Р. Чистая архитектура. Искусство разработки программного обеспечения / Р. Мартин. – СПб.: Питер, 2022. – 416 с.
2. Губин, А. С. Анализ подхода к разработке приложений с чистой архитектурой / А. С. Губин, Н. В. Тутова // Телекоммуникации и информационные технологии. – 2022. – Т. 9, № 1. – С. 28–37.
3. Nugroho, Y. N. Clean architecture implementation impacts on maintainability aspect for backend system code base / Y. N. Nugroho, D. S. Kusumo, M. J. Alibasa // 2022 10th International Conference on Information and Communication Technology (ICoICT) : [proceedings, June 1–3, 2022]. – IEEE, 2022. – P. 134–139.
4. Guamán, D. Classifying model-view-controller software applications using self-organizing maps / D. Guamán, S. Delgado, J. Pérez // IEEE Access. – 2021. – Vol. 9. – P. 45201–45229.
5. Косяков, А., и др. Системная инженерия. Принципы и практика / А. Косяков, … – М.: ЛитРес, 2022. – 312 с.
6. Cockburn, A. Hexagonal architecture / A. Cockburn // The Pattern: Ports and Adapters. – 2005.
7. Spring. Core Technologies [Электронный ресурс]. – Режим доступа:
   https://docs.spring.io/spring-framework/reference/core.html (дата обращения: 12.01.2025).
8. Dementyev, V. Layered Design for Ruby on Rails Applications: Discover practical design patterns for maintainable web applications / V. Dementyev. – [S. l.]: Leanpub, 2023. – 298 p.