Один бэкенд, а не три приложения с общим дизайном
Мобильное приложение, сайт и киоск самообслуживания в этой архитектуре — это три разных интерфейса поверх одного и того же бэкенда. Меню, цены, стоп-листы, лояльность и промомеханики существуют в системе один раз; то, что видит пользователь в конкретном канале, — это представление одних и тех же данных, а не отдельная копия.
Практическая причина так делать — не эстетика единообразия, а надёжность данных. Если бы у киоска была своя логика забора цен, а у приложения своя, любое изменение — новая акция, изменение стоп-листа при внезапной нехватке ингредиента — нужно было бы вносить в двух местах и следить, чтобы они не разъехались. При одном бэкенде изменение происходит один раз и мгновенно видно во всех каналах.
Меню зависит от конкретного ресторана, а не от абстрактной сети
Ключевая сложность в том, что «меню сети» — это не единый статичный список. Один и тот же ресторан бренда в разных городах может продавать одно и то же блюдо по разным ценам; не в каждой точке есть, например, фритюр для жареных позиций, поэтому часть меню в одних ресторанах доступна, а в других — нет.
Поэтому архитектура строится так: есть эталонное меню на уровне всей сети — актуальный список блюд, техкарт, модификаторов, — и есть слой сопоставления, который связывает эталонную позицию с её локальным аналогом в конкретном ресторане (подробно этот механизм разобран в статье «Как объединить разрозненные iiko-базы ресторанной франшизы»). Когда пользователь выбирает ресторан или указывает адрес доставки, интерфейс — неважно, сайт это, приложение или киоск — запрашивает не абстрактное меню сети, а меню, цены и стоп-листы именно этой точки. Если блюдо недоступно в выбранном ресторане, интерфейс сообщает об этом прямо на экране, а не после оформления заказа.
Один и тот же заказ — разный путь оплаты
Разница между каналами начинается именно там, где она объективно нужна. В мобильном приложении и на сайте — привычный путь: выбор способа доставки или самовывоза, ввод адреса, оплата картой через платёжный шлюз. В киоске — оплата через терминал эквайринга, встроенный в устройство, авторизация по номеру телефона и коду из смс вместо личного кабинета, а после завершения заказа — сброс сессии и очистка корзины, потому что устройство стоит в зале и им пользуется следующий гость.
Всё, что происходит до и после оплаты — состав меню, расчёт стоимости, применение бонусов и промоакций, отправка заказа в конкретный ресторан, — использует одну и ту же бизнес-логику вне зависимости от канала.
Чек-лист: что проверить перед добавлением нового канала
Когда к сайту и приложению добавляется киоск, экран в зале или любой новый канал, стоит явно сверить пять вещей:
- Источник меню один. Новый канал не заводит собственную копию меню — он читает то же эталонное меню и те же связи с базами ресторанов, что и остальные каналы.
- Доступность считается на уровне ресторана, а не сети. Логика «этого блюда нет в этой точке» должна работать одинаково во всех каналах, а не быть особенностью одного из них.
- Оплата и сессия — под конкретный сценарий устройства. Общий бэкенд не означает одинаковый UX оплаты: для публичного устройства нужна своя логика очистки сессии.
- Лояльность и промо не дублируются. Начисления и списания бонусов идут через общий модуль лояльности, а не через отдельную реализацию для нового канала.
- Мониторинг общей логики важнее мониторинга канала. Раз баг в общем слое сразу проявляется во всех каналах, стоит закладывать это в тестирование нового канала — не только его собственный интерфейс, но и то, как он использует общие данные.
Что это даёт при масштабировании на новый канал
Когда сеть добавляет новый канал продаж — экран в зале ресторана, киоск на новой точке, — ему не нужно повторно решать задачи, которые уже решены на уровне платформы: где брать актуальное меню, как учитывать разные цены по городам, как забирать стоп-листы в реальном времени. Новый канал подключается к уже существующему бэкенду и с первого дня работает с той же логикой, что и остальные — тем самым новый канал продаж не превращается в отдельный ИТ-проект каждый раз заново.
Обратная сторона этого подхода — цена ошибки в общем слое выше: если в логике сопоставления цен или стоп-листов появляется баг, он проявляется сразу во всех каналах, а не в одном. Поэтому единый бэкенд для нескольких каналов оправдан именно в масштабе сети из нескольких десятков ресторанов — там, где стоимость поддержки трёх параллельных реализаций одной и той же логики становится ощутимо выше цены общей архитектуры.
Как объединить разрозненные iiko-базы ресторанной франшизы
Читать статью
