Как устроен еком? Разбираем базовые принципы еком-системы

Привет, VC! На связи Антон, техдир Metalcode. У нашей команды 10-летний опыт разработки еком-проектов на php, битрикс. От типовых решений Аспро до сложной кастомной разработки с десятками интеграций.

Хочу написать цикл статей про разработку еком-проектов, отрефлексировать опыт и превратить в полезные кейсы.

Интернет-магазин или еком-система? Какие еще стенды и контуры? Доступным языком про устройство и разработку еком-проектов.

В современном екоме невозможно мыслить только понятием Интернет-магазин. Вместо него существует термин Еком-система — состоящая из набора подсистем, объединенных между собой интеграциями для обмена данными. Так в еком-систему входит складской учет, системы управления клиентами CRM, заказами, витрины (интернет-магазин и не только), системы аналитики, экварйинги, облачные кассы и прочее.

Большие энтерпрайз системы могут состоять из десятков сервисов.

Еком-система может быть построена на базе платформы – готовый набор компонентов, автоматизирующих основные процессы, связанные с товарами, клиентами и заказами. Такие комплексные решения могут одновременно содержать функциональность целых классов систем: PIM, CRM, OMS, CMS и других. Сравнение платформ электронной коммерции. В наш фокус больше всего попадает российская система Ensi. Платформа подходит для крупного проекта.

Альтернативой являются системы построенные вручную. Нередко это учет в 1С, магазин на Битрикс/ Laravel, облачные или коробочные CRM и тд. Их объединяют интеграции. Иногда этот обмен данными работает "из коробки", но чаще требуется дорабатывать под бизнес требования. Мы много работаем с этим стеком и понимаем его устройство. Такой формат подходит для небольшого и среднего проекта.

Интернет-магазин играет не последнюю роль, так как именно с ним взаимодействует покупатель. При этом часто витриной выступает не только магазин, но и мобильное приложение, и даже маркетплейсы.

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

Маркетплейсы с технической точки зрения также встраиваются в еком-систему. Например, интегрируем их в складской учет 1С: отдаем в маркеты остатки по товарам, обрабатываем заказы, формируем отчеты комиссионера, передаем в бухгалтерию и так далее.

Мало того, что сама еком-система составная, для разработки нам требуется несколько ее копий. Эти копии называются стендами (или контурами).

Зачем? Чтобы сократить риски бизнеса, изменения и доработки тестируется отдельно от основного проекта, с которым взаимодействуют покупатели и бизнес.

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

На проекте должно быть минимум два стенда: продовый (prod) и тестовый (stage). Плюс несколько копий для разработки и тестирования.

Так приходится разворачивать копии CRM, 1С, сайта и других составляющих еком-системы, которые позволяют это делать (а позволяют обычно только системы размещенные на своих серверах). Облачные сервисы менее адаптивны в этом смысле, но иногда в них есть тестовый режим.

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

И самое главное, что стенды должны быть связаны между собой системами доставки кода. В маленьких проектах этого можно достичь небольшими ресурсами (контроль версий + миграции баз данных). Для крупных есть целый набор практик CI / CD.

Тестовый стенд выступает в роли того места, куда сливаются изменения от всех разработчиков и команд, там происходят финальные тесты.

Также в рамках понятия еком-системы важно отметить, что ее обслуживает несколько команд. Редко одна команда автоматизирует склады в 1С и они же развивают CRM.

Каждая команда должна учитывать общую архитектуру системы и взаимосвязи. Невозможно просто дорабатывать интернет-магазин и не учитывать все остальное.

— Как достигаем общего знания между командами на проекте? Спойлер: рисуем целевую архитектуру, готовим документацию, описываем бизнес-процессы.

— Как устроен цикл разработки применительно к описанной архитектуре нескольких стендов еком-системы.