MedusaStore полезнее читать как карту готового ecommerce-проекта, а не как описание одной витрины. Здесь важен не только storefront StudioPro, а весь путь вокруг магазина: покупатель выбирает товар и оформляет заказ, администратор управляет commerce-данными, маркетолог ведёт контент и кампании, поддержка разбирает отзывы и коммуникации, а разработчик получает повторяемую основу для следующего проекта.

Поэтому это не просто набор интеграций, собранных рядом с Medusa. В проекте уже видны связанные продуктовые маршруты: каталог, корзина, checkout, аккаунт, отзывы, CMS-страницы, рассылочные настройки, российские интеграции и staging-деплой. Одни части отвечают за пользовательский опыт, другие — за операционную работу магазина, третьи — за безопасное развёртывание и проверку. При этом часть функций намеренно оставлена opt-in или default-off, чтобы не выдавать подготовленную интеграцию за production-live сервис.

Сценарий покупателя

Для покупателя MedusaStore выглядит как обычный интернет-магазин: он приходит в storefront StudioPro, смотрит витрину, переходит в каталог, открывает карточку товара, добавляет позицию в корзину и проходит checkout. За этим привычным маршрутом стоит Medusa Store API: backend остаётся source of truth для товаров, цен, корзин, заказов и checkout-состояний.

В пользовательском слое есть несколько важных деталей:

• catalog и product details routes для просмотра ассортимента;
• cart и checkout flow через прямые Store API endpoints;
• account routes для пользовательской зоны;
• reviews: публичные отзывы, rating summary, helpful votes, image uploads и moderation flow;
• static contacts и content pages, которые могут приходить из Payload при включённом CMS-слое.

VK ID onboarding предусмотрен как отдельный входной сценарий, чтобы пользователь мог зайти не только через классический email-флоу. Если у пользователя нет нормального email, используется placeholder email. При этом checkout gate не должен молча пропускать состояние, где для заказа не хватает обязательных данных: удобный вход не отменяет проверку заказа перед оформлением.

Сценарий администратора магазина

Администратор видит другую сторону той же системы: не каталог как картинку для покупателя, а commerce-операции за ним. Работа идёт через Medusa Admin и кастомные расширения. Backend содержит modules, workflows, subscribers, routes и admin widgets, поэтому магазин не ограничивается стандартной витриной Medusa.

Ключевые зоны администрирования:

• товары, варианты, цены и коммерческие сущности Medusa;
• moderation для отзывов;
• статусы заказов и fulfillment baseline;
• ручная доставка как базовый безопасный режим;
• opt-in интеграции YooKassa и ApiShip/Gorgo;
• transactional moderation emails и notification flows.

Live shipment execution через ApiShip выключен по умолчанию переменной APISHIP_SHIPMENT_EXECUTION_ENABLED. Это правильная граница: рассчитать или подготовить доставку можно безопаснее, чем автоматически создавать реальные отправления без отдельной операционной проверки.

Сценарий маркетолога

Маркетологу важен не только каталог: магазин должен объяснять, куда попал посетитель, какие страницы вокруг покупки доступны и как с пользователем продолжается коммуникация после первого касания. В MedusaStore для этого есть Payload CMS как отдельный content/admin слой: Pages, Posts, Media, Users, MarketingCampaigns, а также globals Navigation, Footer и SiteSettings.

Через этот слой можно вести страницы, новости, медиа, настройки навигации и маркетинговые кампании, не смешивая контент с commerce-ядром. В проекте предусмотрены drafts, preview и revalidation, но Payload не становится commerce backend. Он не хранит provider secrets, платежную правду или заказы.

Маркетинговый контур связан с preferences, campaigns, delivery journal, unsubscribe и double opt-in. Это не «просто форма подписки», а заготовка для нормальной коммуникационной дисциплины: кто согласился, на что согласился, что отправлено и как пользователь может отказаться.

Сценарий поддержки

Поддержка оказывается там, где пользовательский путь перестаёт быть линейным: отзыв ждёт модерации, уведомление не должно потеряться, а в профиле или checkout появляются спорные состояния. В проекте есть reviews subsystem: публичные отзывы, rating summary, helpful votes, image uploads, moderation и административные widgets/routes.

Уведомления могут идти через local, SMTP, UniSender, SMS, VK или fallback/disabled semantics. Это удобно для staging и разработки: отсутствие production-провайдера не должно ломать весь checkout или moderation flow. Но для production всё равно нужен отдельный проход по SMTP/mailserver, deliverability, шаблонам и retry-поведению, потому что коммуникации — часть сервиса, а не декоративное дополнение.

Сценарий разработчика или агентства

Для разработчика или агентства MedusaStore ценен как повторяемая база, которую можно разбирать не по отдельным папкам, а по жизненному циклу магазина: поднять окружение, проверить backend, посмотреть storefront, подключить Payload, прогнать smoke и вывести staging. Root-level scripts управляют env, bootstrap, local dev, backend, storefront, Payload, smoke и staging deploy. Локально Docker Compose поднимает PostgreSQL, Redis и Medusa backend, а storefront и Payload чаще идут host processes.

На staging работает production-mode compose stack: PostgreSQL, Redis, Medusa backend, Payload CMS, Storefront, Caddy и optional AI Assistant. Canonical deploy — GitHub Actions Deploy Staging, secrets — только через GitHub Secrets/Variables. Так проект показывает не только «что написано», но и как это должно жить за пределами локальной демонстрации.

В этом смысле MedusaStore хорошо ложится рядом с архитектурным разбором проекта и инфраструктурными заметками вроде deploy: ценность не только в коде, но и в том, как система разворачивается и проверяется.

Optional assistant

AI Assistant присутствует как optional слой: FastAPI service, backend adapter routes, reindex intents и storefront/widget integration. Но он выключен по умолчанию и не должен описываться как live-функция магазина. Это скорее подготовленная поверхность для будущего консультанта по каталогу, заказам, контенту и поддержке, который может появиться рядом с магазином, но не подменяет базовый ecommerce-flow.

Подробнее этот слой вынесен отдельно в roadmap production hardening, потому что смешивать ассистента с базовым checkout было бы нечестно: магазин может работать без него, а production-готовность ассистента требует отдельной безопасности, rate limiting и эксплуатационных правил.

В итоге обзор показывает MedusaStore как связанную ecommerce-систему: storefront опирается на backend, контент живёт в своём слое, операционные сценарии отделены от маркетинговых, а экспериментальные возможности явно помечены как optional. Главная ценность проекта — не в одном эффектном экране, а в том, что разные участники магазина могут двигаться по своим сценариям, оставаясь внутри одной понятной архитектуры.