Каталог, который PrestaShop не мог смоделировать.
Лейбл музыки для сна и wellness ведёт гибридный каталог: цифровое аудио — звуковые ландшафты для сна, медитативные сессии, оригинальные композиции — наряду с физическими носителями и брендовыми аксессуарами. Клиентский опыт живёт или умирает на одном взаимодействии: смогу ли я услышать достаточно этого трека, чтобы решиться на покупку, затем добавить его в корзину вместе с виниловым изданием и оформить заказ в одном потоке?
Коробочный PrestaShop 1.7 не моделировал ничего из этого. Он знал товары и цены. Он не знал аудиотреков с настраиваемой границей фрагмента. Он не знал композиторов и дикторов как контентные сущности первого класса. Он не знал, что маркетинговой команде нужно перекомпоновать главную страницу во вторник, не открывая редактор кода.
Бриф был прямым: построить e-commerce-поверхность, которая подходит этому бизнесу, а не бизнес, который подходит платформе.
Пять модулей, благодаря которым PrestaShop свободно заговорил на языке предметной области.
Мы расширили PrestaShop 1.7.4 — PHP 5.6, Symfony 3.4, Doctrine, MySQL, Smarty — пятью заказными модулями, кастомной темой и брендированными шаблонами PDF-счетов. Ни один из модулей не был взят с маркетплейса. Все пять написаны с нуля под конкретную форму предметной области.
Модуль музыкального плеера дал каждому цифровому товару воспроизводимую идентичность: метаданные трека, полную длительность, настраиваемое артистом для каждого трека время отсечения фрагмента и встроенный плеер с перемоткой. Артист решает, сколько проигрывается до оформления. Это решение — бизнес-правило; оно живёт в модели данных, а не в JavaScript-хаках поверх дефолтного шаблона товара.
Модуль профилей авторов сделал композиторов и дикторов сущностями первого класса с собственными страницами профилей, биографиями и дискографиями. Трек знает своего автора. Страница автора перечисляет его треки. Эта связь запрашиваема и управляема из админ-панели.
Модуль конструктора главной страницы дал маркетинговой команде структурированную поверхность — блоки в шапке, баннеры, CTA, — которую можно редактировать, не трогая тему. Модуль product-block отвечал за курируемые витрины на главной по категориям. Модуль conditions дал юристам self-service-поверхность для управления условиями использования. В сочетании с одностраничным потоком SuperCheckout и региональной платёжной интеграцией CM-CIC оформление собирало email в точке продажи и проводило расчёт через региональный процессор клиента без кастомного платёжного шлюза.
Кастомные шаблоны PDF-счетов — 877 строк, брендированные — формировали чеки на стороне сервера. Покупатель получает чек, который выглядит как бренд, у которого он только что совершил покупку.
- F · 01Модуль музыкального плеера
- Метаданные трека, длительность, настраиваемое время отсечения фрагмента и встроенный плеер с перемоткой. Артист задаёт, сколько проигрывается до оформления; это правило живёт в модели данных.
- F · 02Модуль профилей авторов
- Композиторы и дикторы как сущности первого класса в админке со страницами профилей, биографиями и дискографиями. Треки ссылаются на авторов; страницы авторов перечисляют треки.
- F · 03Модуль конструктора главной страницы
- Структурированные блоки в шапке, баннеры и CTA, которые маркетинговая команда редактирует из админ-панели — без доступа к теме, без дежурного инженера.
- F · 04Модуль product-block
- Курируемые витрины товаров на главной, организованные по категориям. Оператор решает, что появляется на первой странице, не трогая шаблон.
- F · 05Одностраничное оформление + региональная оплата
- Одностраничный поток SuperCheckout с региональной обработкой платежей CM-CIC и сбором email через Mailchimp в точке продажи. Цифровое и физическое в одной корзине, одно оформление.
- F · 06PDF-счета в стиле бренда
- Формирование счетов на стороне сервера — 877 строк кастомных шаблонов. Чеки, которые выглядят как бренд, у которого покупатель только что совершил покупку.
Расширяйте платформу, а не переписывайте её.
Соблазн в проекте вроде этого — заключить, что платформа неправильная, и начать заново. PrestaShop не знает, что такое граница превью, — так перейдём на кастомное Symfony-приложение, потянемся к headless-стеку, будем доказывать необходимость совсем другой платформы.
Ничто из этого не было оправдано. Система модулей PrestaShop существует именно для этого. Платформа берёт на себя управление каталогом, обработку заказов, склад, налоги, мультивалютность и десятилетие пограничных случаев e-commerce, которые неинтересно переписывать. Пробелом было моделирование предметной области — метаданные аудио, сущности авторов, редактируемая главная — и этот пробел оказался ровно того размера, что нужен для пяти модулей.
Расширяйте платформу только там, где её словарь неверен. Везде, где он верен, дайте ей делать работу.
Четыре месяца, с ноября 2018 по март 2019 года, 356 коммитов. Объём расширения был выверен относительно того, что платформа уже делала хорошо. Модули изолированы и чётко ограничены. Остальное — это PrestaShop. Это ограничение — дисциплина не меньше, чем решение: если расширять только там, где соответствие действительно неверно, система, которую наследует следующий инженер, остаётся читаемой.
Платформа, которая заговорила на языке бренда.
Витрина вышла с каталогом, которым оператор мог управлять, оформлением, обрабатывающим цифровое и физическое в одном потоке, и главной страницей, которую маркетинговая команда могла редактировать без обращения в поддержку.
Платформа знала, что такое аудиотрек. Она знала, что такое автор. Она знала, что фрагмент проигрывается заданное окно времени, а затем требует решения о покупке. Это не функции, прикрученные сбоку к типовой витрине, — это модель предметной области, выраженная в коде и выведенная в админ-панель.
356 коммитов, 4 месяца, 5 кастомных модулей. Оператор запустился в срок и управлял каталогом с первого дня без инженерной поддержки.
Наконец-то это стало похоже на наш магазин, а не на магазин PrestaShop с нашим логотипом.