05.03.2024
изображение статьи
Подход к разработке, заключающийся в выборе лучших в своем классе коммерческих компонентов и объединении или "компоновке" их в пользовательское приложение, созданное для конкретных потребностей бизнеса называют Composable commerce

Компоненты решения взаимодействуют через API и могут быть заменены без ущерба для других частей системы. Решение на базе Composable меняет подход к созданию коммерческих систем и оказывает большое влияние на будущее e-commerce.

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

Цель Composable сосредоточиться на решении конкретных бизнес-потребностей, упрощая их восприятие, интеграцию и использование. Такой подход снижает сложность по сравнению с жестким монолитом или сложной архитектурой микросервисов. Решения которые являются элементами модульного подхода: Frontend as a Service (FaaS), системы управления контентом (CMS), платежи, отзывы или поисковые решения в качестве самостоятельных продуктов.

Отличия composable commerce от традиционной коммерции

При использовании composable подхода архитектура компании не привязана к монолитным приложениям, и можно пробовать лучшие модульные технологии без ограничений лицензий от вендора. Структура этого нового подхода называется "Packaged Business Capability". Gartner определяет этот термин как "программные компоненты, представляющие собой четко определенную бизнес-возможность". 

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

Монолитное приложение – это одноуровневое приложение, в котором разные компоненты объединены в единое программное обеспечение, одну платформу. Примером может быть платформа для электронной коммерции, которое может включать веб-сервер, балансировщик нагрузки, сервис каталога, предоставляющий изображения продуктов, систему заказов, сервисы оплаты и доставки и т.д.

На первый взгляд это может быть очень удобно, так как все в одном месте и в одном приложении. Однако большая монолитная кодовая база представляет собой огромную сложность для разработчика. В результате скорость разработки замедляется. Частичное масштабирование невозможно. Если вы хотите внести изменения в модуль отзывов, вам нужно обновить всю систему, а не только эту часть.

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

Composable commerce и headless commerce

Термины "composable " и headless часто используются взаимозаменяемо, но они имеют по крайней мере одно основное различие. Composable commerce выходит за рамки headless, отделяя интерфейсный стек от серверной части и выбирая лучшие технологии для построения общего бизнес-решения. Для многих приложений электронной коммерции переход на headless является первым небольшим шагом на пути к гибкой архитектуре. Разработчики внешнего интерфейса могут работать независимо от бэкенд-команд, без ущерба для и без того хрупкого и разросшегося монолита. Переход на Composable, разумно начинать с Front end части, потому что именно с ней взаимодействуют клиенты и, как правило, это увеличивает производительность страниц.

Composable переводит гибкость, предлагаемую headless решениями, на новый уровень. В рамках headless архитектуры функциональные возможности могут быть ограничены бизнес-логикой, заключенной в монолите, если основной платформой по-прежнему является full-stack движок. Composable commerce ориентирована в первую очередь на API, поскольку программное обеспечение взаимодействует через API для создания сложных бизнес-решений. Однако эти элементы также могут работать независимо, что означает один фрагмент головоломки можно заменить, не затрагивая другие части системы.

Что представляют собой Package Business Capabilities (PBC)и в чем их отличие от микросервисов?

Package Business Capabilities имеют много общего с микросервисами, но не обязательно имеют явно определенный размер, а варьируются от микро- до макро-возможностей. Цель PBC заключается в решении конкретных бизнес-задач, оставаясь простыми в использовании, интеграции и освоении.

Другими словами, микросервисы ­ это способ разделения приложения на небольшие функции. PBC ­ это сознательно сгруппированные, агрегированные наборы микросервисов, они также могут объединяться и интегрироваться в современные технологические решения для решения более масштабных бизнес-задач и стратегий.

Согласно определению Gartner, PBC включают в себя группу API (ограниченный набор), обслуживающих конкретную бизнес-функцию, в отличие от микросервисов, которые имеют более узкую область применения и более детализированы. Проще говоря, PBC ­ это приложение или сервис, построенные вокруг конкретной бизнес-функции.

Нельзя оставить без внимания MACH архитектуру (Microservices, API-First, Cloud-Native, and Headless), ее компоненты являются предшественниками PBC. Этот подход фокусируется на множестве модульных приложений, лучших в своем классе, от разных поставщиков, вместо того, чтобы полагаться на одного.

Преимущества Composable commerce:

  1. Подход облегчает работу команд разработки. Обновления не становятся кошмаром, и процессы программирования работают быстрее, минимизируя риск сбоев.
  2. Возможность выбирать только необходимые функции и разных поставщиков снижает операционные расходы.
  3. Организация собственного технологического стека дает свободу определения пользовательского опыта и бизнес-логики, так как продажи ведутся по множеству каналов и компании нуждаются в гибкой и масштабируемой платформе. 
  4. Использование Composable Commerce позволяет сначала переносить приоритетные функции и постепенно разбирать монолит. Это гораздо более безопасный подход, сводящий к минимуму риск потенциальных сбоев. Более того, это позволяет предприятиям тщательно проанализировать свои цели и установить разумный - с точки зрения затрат и сроков - график их достижения.