Архитектура мобильного приложения: как устроено приложение интернет-магазина

Покупатель видит в приложении магазина каталог, корзину и оплату. За этими экранами работают серверная часть, копии данных и обмен с учётной системой, CRM и банком. От того, как связаны эти части, зависят скорость каталога, устойчивость в распродажу и цена каждой доработки. Дальше — из каких слоёв состоит приложение, как устроены кэш каталога и интеграции, как следить за ошибками и какие архитектурные решения обходятся дороже всего.

17 сентября 2026 Технологии 17 мин чтения

---

Что такое архитектура мобильного приложения простыми словами

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

Удобно представить офлайн-магазин. Торговый зал с витринами — это экраны приложения. Склад и товароведы — серверная часть, которая хранит каталог и знает остатки. Бухгалтерия — учётная система, например 1С. Касса и терминал — эквайринг. Если продавец за каждой вещью бежит в бухгалтерию, очередь растёт. Если склад и касса не сверяют остатки, магазин продаёт то, чего нет. В приложении те же проблемы решает архитектура.

Типичное приложение интернет-магазина состоит из трёх больших частей:

• Клиентская часть. Приложение на iPhone и Android: экраны, навигация, корзина, хранение последних загруженных данных на устройстве.
• Серверная часть. Программа на сервере компании: копия каталога, расчёт корзины и скидок, приём заказов, отправка push-уведомлений, журнал ошибок.
• Внешние системы. Учётная система, CRM и программа лояльности, эквайринг, службы доставки, маркетплейсы, сервисы аналитики.

Части общаются через API — программный интерфейс, набор договорённостей, какие запросы можно отправить и в каком виде придёт ответ. Как проектируют такой интерфейс, разобрано в статье о проектировании REST API. Разработчики Flutter и Android описывают похожее разделение в официальных руководствах: Guide to app architecture для Flutter и руководство по архитектуре Android-приложений.

Зачем архитектура владельцу интернет-магазина

Покупатель не видит архитектуру, но замечает её последствия: каталог открывается за секунду или за пять, заказ доходит до склада или теряется, скидка в приложении совпадает с сайтом или нет. Для бизнеса архитектура влияет на четыре вещи.

1. Выручка в пиковые дни. В распродажу нагрузка вырастает в разы. Если каждый просмотр товара превращается в запрос к учётной системе, она перестаёт отвечать, и покупатели уходят. Подготовку к пикам подробно описывает материал о высоконагруженных системах в e-commerce.
2. Цена доработок. Когда модули разделены, новую механику лояльности добавляют, не трогая корзину и оплату. Когда всё связано со всем, любая правка требует проверки всего приложения и дорожает.
3. Скорость обновлений. Часть изменений — баннеры, подборки, тексты акций, порядок блоков на главной — можно менять с сервера без новой версии в App Store и Google Play. Остальное требует выпуска версии и проверки магазина приложений.
4. Независимость от подрядчика. Понятная структура, документация и разделённые модули позволяют передать проект другой команде без переписывания. Запутанную архитектуру новой команде проще переписать, чем понять.

Если приложение уже работает и вызывает вопросы по стабильности или стоимости изменений, начинают с аудита кода — он показывает, как устроены связи между частями и что мешает развитию.

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

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

Главное правило разделения: правила бизнеса живут на сервере, а не в приложении. Если скидка считается в коде на телефоне, для её изменения нужна новая версия приложения, а у части покупателей ещё месяцы будет стоять старая. Кроме того, приложение и сайт начинают считать цены по-разному. Когда расчёт один и находится на сервере, сайт и приложение показывают одну цену, а правило меняют один раз.

На клиентской стороне Flutter позволяет держать интерфейс, состояние и работу с данными в одном коде для iOS и Android. Как устроен фреймворк, объясняет материал что такое Flutter, а на чём теряется скорость отрисовки экранов — разбор производительности Flutter-приложения.

Модули: каталог, корзина, оплата и лояльность по отдельности

Слои делят код по горизонтали, модули — по вертикали, по функциям магазина. Модуль объединяет всё, что относится к одной функции: экраны, правила и обмен данными. Хорошо разделённые модули общаются друг с другом через понятные точки входа и не лезут во внутренности соседей.

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

Данные и кэш каталога: почему приложение не ходит в 1С за каждым товаром

Учётная система хранит правду о товарах, ценах и остатках, но не рассчитана на тысячи одновременных запросов от покупателей. Поэтому приложение берёт каталог не из 1С напрямую, а из собственной копии на серверной части. Эту копию регулярно обновляют из учётной системы.

Кэш — это быстрая временная копия данных, которую отдают вместо повторного обращения к первоисточнику. В приложении магазина кэш бывает на двух уровнях:

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

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

Сеть доставки контента (CDN) — это набор серверов в разных городах, который отдаёт фото товаров с ближайшего к покупателю узла. Для каталога с тысячами позиций именно картинки составляют основной объём загрузки, поэтому их оптимизация заметна сильнее, чем ускорение кода. Как Flutter-приложение хранит данные на устройстве и работает при плохой связи, описывает руководство Offline-first support в документации Flutter.

Правило, которое нельзя нарушать

Кэш ускоряет просмотр, но не участвует в расчёте денег. Перед оплатой серверная часть заново сверяет цену, остаток, промокод и доступные баллы с первоисточником. Если за время выбора товар закончился, покупатель увидит это до списания денег, а не в звонке оператора после заказа. Так устроено приложение сети кофеен One Price Coffee, запущенное за 2 месяца: корзина повторно проверяется по стоп-листу перед оплатой — подробности в разделе с кейсами.

Интеграции: как приложение обменивается данными с 1С, CRM и банком

Интеграция — это автоматический обмен данными между приложением и другой системой компании. У интернет-магазина их обычно пять–семь, и именно на них приходится основная часть уникальной работы в проекте: каталог и корзина похожи у разных магазинов, а набор учётных систем, программ лояльности и служб доставки у каждого свой.

Четыре принципа надёжных интеграций

1. Приложение не обращается к внешним системам напрямую. Все обмены идут через серверную часть. Ключи доступа к 1С, CRM и банку не хранятся на телефоне, а замена службы доставки или программы лояльности не требует новой версии приложения в сторах.
2. Заказ сначала сохраняется у себя, потом уходит в учёт. Серверная часть принимает заказ, записывает его в свою базу и ставит в очередь на передачу. Если 1С в этот момент недоступна, заказ не теряется: система повторит отправку, когда учёт снова ответит.
3. Банк сообщает о платеже сам. Результат оплаты приходит на сервер через вебхук — автоматическое уведомление, которое банк отправляет по заранее согласованному адресу. Даже если покупатель закрыл приложение сразу после оплаты, заказ получит статус «оплачен».
4. У каждого обмена есть журнал. Когда заказ не дошёл до склада, команда видит, на каком шаге и с какой ошибкой он остановился, и не восстанавливает цепочку по жалобе покупателя.

Отдельная работа — сопоставление справочников. Артикулы, склады, города и статусы заказов в учётной системе и в приложении должны совпадать. Особенно это важно для сетей с региональными складами: покупатель должен видеть остатки и цены своего города. Как готовят учётную систему к обмену, разобрано в статье об автоматизации учёта товара в рознице с 1С; услуги — интеграция с ERP для интернет-магазина и интеграция приложения с CRM. Требования к оплате описаны в материале о безопасности платежей в мобильном приложении.

Мониторинг ошибок: как узнать о сбое раньше покупателей

Ошибки есть в любом приложении: редкая модель телефона, обрыв связи во время оплаты, неожиданный ответ учётной системы. Вопрос в том, кто узнает о проблеме первым — команда или покупатель, который напишет отзыв с одной звездой. Мониторинг — это набор инструментов, которые собирают ошибки автоматически и сообщают о них команде.

В приложении магазина следят за тремя уровнями:

Магазины приложений тоже следят за стабильностью. Google Play в разделе Android vitals публикует пороги: если доля пользователей, столкнувшихся со сбоем, превышает 1,09% за день, стор может реже показывать приложение в поиске и рекомендациях. Apple собирает отчёты о сбоях с устройств пользователей — порядок описан в документации Xcode.

Мониторинг полезен, только когда у каждой ошибки есть владелец. Поэтому оповещения делят по важности: сбой оплаты или остановка обмена с 1С поднимают дежурного сразу, а редкая ошибка отрисовки на старой модели телефона попадает в план ближайшего выпуска. Связанная тема — продуктовая аналитика, о ней материал аналитика мобильного приложения: метрики и инструменты.

Типичные ошибки архитектуры и их цена

Большинство архитектурных проблем не видны при запуске. Они проявляются через полгода–год: в первую крупную распродажу, при смене учётной системы, при попытке добавить сайт на той же логике. Восемь решений, которые чаще всего приходится переделывать:

У разделённой архитектуры есть и цена: на небольшом проекте с десятком экранов и одной интеграцией полноценные слои, очереди и версионирование API добавляют работы на старте. Для приложения-визитки без оплаты и учёта такая схема избыточна. Для интернет-магазина с каталогом, оплатой и программой лояльности она окупается на первой крупной доработке. Как тестируют связку приложения, сервера и интеграций целиком, описано в статье об E2E-тестировании приложения.

Метрики: как проверить, что архитектура работает

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

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

Чек-лист: вопросы об архитектуре к подрядчику

Заказчику не нужно разбираться в коде, чтобы проверить архитектуру. Достаточно задать вопросы и попросить показать ответы на схеме:

1. Где считаются цены, скидки и бонусы — на сервере или в приложении? Одинаково ли это для сайта и приложения?
2. Обращается ли приложение к 1С напрямую? Если нет, как часто обновляется копия каталога и остатков?
3. Что происходит с заказом, если учётная система недоступна в момент оформления?
4. Сверяются ли цена и остаток перед оплатой?
5. Какие части главной страницы и акций можно менять без выпуска новой версии?
6. Как работает приложение при слабой связи и без интернета?
7. Каким сервисом собираются ошибки приложения и сервера и кто получает оповещения?
8. Как будут поддерживаться старые версии приложения после изменения сервера?
9. Какую нагрузку выдерживает система и как это проверяли?
10. Кому принадлежат исходный код, серверы и доступы к сервисам и как проект передаётся другой команде?

Если на половину вопросов ответ «уточним позже», архитектура, скорее всего, ещё не продумана. Проверить уже работающее приложение помогает аудит мобильного приложения; из чего он состоит, рассказывает статья о комплексном аудите мобильного приложения. Полный порядок действий заказчика — в чек-листе заказа приложения для интернет-магазина.

Как это устроено на модульной платформе

Описанные слои и модули можно спроектировать под каждый проект заново, а можно собрать из готовых блоков. Модульная Flutter-платформа FITTIN, внесённая в реестр российского ПО Минцифры (№ 2487103), работает по второму пути. Каталог, поиск и фильтры, корзина, оплата, личный кабинет, лояльность, push-уведомления, сториз, аналитика и мониторинг ошибок уже написаны и проверены на проектах розничных сетей. Под бренд их настраивают, оформляют и подключают к системам магазина.

Архитектурно платформа устроена так же, как в разделах выше:

• Клиентская часть на Flutter. Из одного кода собираются приложения для App Store, Google Play и RuStore, а также сайт интернет-магазина. Как работает связка сайта и приложения на одной кодовой базе, описано в статье о приложении и сайте на Flutter.
• Серверная часть на Python. Копия каталога, расчёт корзины, приём заказов и журналы обменов живут на сервере, а не в приложении. Подробнее о стеке — на странице разработки на Django.
• Готовые интеграции. 1С, CRM и системы лояльности, эквайринг, службы доставки СДЭК, Boxberry и Почта России, маркетплейсы Wildberries, Ozon и Яндекс Маркет.
• Кастомные доработки на исходном коде. Уникальные сценарии — конструктор товара, особая логистика, собственная механика лояльности — дописываются поверх модулей, не ломая базовый набор.

Модель оплаты состоит из трёх частей. Первая — единоразовая интеграция платформы под бренд, до 30 рабочих дней. Вторая — ежемесячные лицензионные платежи, в которые уже включены все затраты на техническую поддержку команды FITTIN: мониторинг ошибок, обновления модулей и безопасности, совместимость с новыми версиями iOS и Android. Для базового сопровождения своя команда разработки не требуется. Третья — новый функционал и доработки оплачиваются отдельно, по модели Time & Materials: оценка в часах и смета до старта задачи. Актуальные пакеты — на странице тарифов, ориентир под свой набор функций можно получить на калькуляторе стоимости.

Готовые модули подходят не всем. Если продукт строится вокруг нестандартной логики, которой нет в розничной торговле, выгоднее проектировать архитектуру с нуля — такие проекты описаны на странице мобильных приложений на заказ. Сравнение подходов с расходами на несколько лет вперёд — в материале о стоимости владения приложением, а устройство платформы по модулям — в разборе модульной платформы для e-commerce.

Кейсы: архитектурные решения в приложениях магазинов

Четыре проекта, где архитектурные решения из этой статьи видны в работе приложения. Данные — со страниц кейсов.

Как приложения магазинов устроены с точки зрения функций, показано на страницах мобильных приложений для интернет-магазинов и Flutter-приложений для e-commerce. Остальные проекты — в разделе кейсов.

Итог: архитектура приложения на одной странице

Материалы по теме:

• Нагрузка и скорость: высоконагруженные системы в e-commerce, производительность Flutter-приложения.
• Серверная часть и интеграции: проектирование REST API, интеграция Mindbox с кастомными событиями.
• Сопровождение: стоимость поддержки приложения, техническая поддержка приложений.

Что делать дальше:

• Описать сценарии, системы и данные для обмена — разработка технического задания.
• Проверить архитектуру работающего приложения — аудит кода и аудит мобильного приложения.
• Посчитать бюджет — калькулятор стоимости и тарифы; обсудить проект — контакты или форма ниже.

Часто задаваемые вопросы

Чем архитектура приложения интернет-магазина отличается от архитектуры сайта?

Серверная часть, база данных и интеграции у сайта и приложения могут быть общими — и так удобнее всего. Отличается клиентская часть: приложение хранит данные на устройстве, работает при слабой связи, получает push-уведомления и обновляется через App Store и Google Play. Поэтому у части покупателей долго стоят старые версии, и сервер должен их поддерживать. Сайт обновляется у всех сразу.

Можно ли подключить приложение напрямую к 1С без своей серверной части?

Технически можно, но для интернет-магазина так делать не стоит. Учётная система не рассчитана на тысячи одновременных запросов покупателей и в распродажу перестанет отвечать. Ключи доступа к ней придётся хранить в приложении, а любое изменение обмена потребует новой версии в сторах. Надёжнее держать копию каталога на серверной части и обмениваться с 1С по расписанию и через очередь заказов.

Как часто в приложении обновляются цены и остатки?

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

Будет ли приложение работать без интернета?

Частично. Приложение сохраняет последние загруженные экраны каталога, фото, избранное и данные профиля, поэтому их можно просматривать при слабой связи или без неё. Оформить заказ и оплатить без интернета нельзя: цена, остаток и платёж проверяются на сервере в момент операции. Некоторые функции специально делают доступными офлайн — например, QR-код карты лояльности, который формируется на телефоне.

Как узнать об ошибках в приложении раньше, чем появятся плохие отзывы?

Подключить сбор ошибок с первого выпуска. Сервис вроде Sentry присылает сведения о каждом сбое с моделью телефона и шагами пользователя, журналы сервера показывают ошибки запросов и время ответа, а журналы интеграций — неудачные оплаты и заказы, не дошедшие до 1С. Критичные события отправляют оповещением дежурному сразу. Дополнительно стоит следить за разделом стабильности в Google Play и App Store Connect.

Можно ли поменять учётную систему или CRM, не переделывая приложение?

Да, если приложение обращается к внешним системам только через серверную часть. Тогда при смене CRM или программы лояльности переписывают модуль интеграции на сервере, а приложение на телефонах покупателей продолжает работать с тем же API и не требует новой версии. Если приложение связано с внешней системой напрямую, смена системы означает доработку приложения, выпуск версии и ожидание, пока покупатели обновятся.

Сколько стоит разработать архитектуру приложения интернет-магазина?

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

Материал носит информационно-аналитический характер, отражает оценку команды FITTIN на дату публикации. Пороги стабильности магазинов приложений приведены по документации Google на дату публикации и могут меняться. Названия сторонних сервисов и систем упоминаются для описания архитектурных решений и принадлежат их правообладателям.