Со временем использование API приобретает все более повсеместный характер. BFF (Backend For Frontend) — общепринятый подход, DDD набирает обороты, а принципы проектирования API встречаются повсеместно. Несмотря на все это, мы продолжаем наблюдать, как организации, придерживающиеся всех этих практик, с трудом осваивают новые каналы.
И мы заметили тенденцию к усложнению, которая кроется в нашем BFF-канале. Эта проблема снижает скорость выхода на рынок с каждым новым каналом, который мы добавляем, или с каждым изменением в нашем клиентском опыте.
Давайте начнем с примера. Представьте себе создание платформы, вроде UberEats. Одной из ее ключевых фич является «просмотр» меню ресторанов для доставки или самовывоза еды. С точки зрения архитектуры, эта фича часто выглядит так, как на этой картинке, где оркестрация распределена по разным BFF.
Здесь Mobile BFF оркестрирует вызовы к API ресторанов, меню и предложений для обеспечения возможности "просмотра"1. Другие каналы, как существующие, так и новые, также нуждаются в такой же логике оркестрации. В результате мы получаем более или менее одинаковую логику, продублированную в каждом BFF.
В конечном итоге это приводит к возникновению неразберихи и усложнений во всех каналах. Неоднократно мы сталкивались с такой проблемой в различных организациях. Сосредоточение внимания исключительно на каналах и бизнес-возможностях привело к архитектуре, которая либо:
Упустила концептуализацию клиентского опыта как ограниченного контекста, либо
Спрятала клиентский опыт (непреднамеренно) за рамки других услуг.
В любом случае результат был одинаковым. Этим опытом было трудно поделиться и повторно использовать через каналы.
В этой статье мы представляем:
Кодирование клиентских впечатлений на основе архитектуры в виде API - Experience APIs.
Как Experience APIs становятся доступными для совместного и многократного использования, чтобы обеспечить эволюционную архитектуру.
Преимущества и последствия использования Experience APIs в качестве шаблона проектирования.
Что такое Experience API?
Граница обслуживания, связанная с путешествиями (путями) клиентов как расширение бизнес-возможностей. При таком подходе мы моделируем рабочие процессы клиентов в виде многократно используемых API, не зависящих от канала.
Давайте разберемся в разнице между API для домена (Domain APIs) , Experience APIs и BFF-каналом (Channel BFFs).
Domain APIs: как работает бизнес (так называемые бизнес-возможности).
Experience APIs: как клиент взаимодействует с бизнесом (так называемое путешествие (путь) клиента).
Channel BFFs: канал клиента при взаимодействии с бизнесом (он же контекст клиента).
Приведем пример из практики, который поможет подтвердить это. На приведенной выше диаграмме «Order Management. Управление заказами» — это бизнес-возможность (Domain API). Речь идет о моделировании жизненного цикла заказа и процессов при изменении его статуса.
Но «Past Orders. Прошлые заказы» — это путь клиента (Experience API). Клиентам важно знать, что они заказывали раньше, чтобы снова оформить повторный заказ на эти товары. Для моделирования этого пути посредством API у нас существуют следующие потребности клиентов:
Просмотреть список прошлых заказов GET /past-orders
Просмотр одного заказа из списка GET /past-orders/{id}
Просмотр накопленных баллов за заказ GET /past-orders/{id}/rewards
Поиск прошлых заказов GET /past-orders?query="The good restaurant"
Отметить заказ как любимый PUT /past-orders/{id}/favorite
Оценить позиции заказа POST /past-orders/{id}/item/{item-id}/ratings
Быстрый повторный заказ POST /past-orders/{id}/reorder
Просмотр квитанции заказа GET /past-orders/{id}/receipt
Загрузить квитанцию заказа GET /past-orders/{id}/receipt/download
Получение квитанции заказа по электронной почте POST /past-orders/{id}/receipt/email
Поддержка клиентов POST /past-orders/{id}/complaints
Обратите внимание, что в этом списке отсутствуют такие понятия, как создание заказа или изменение статуса заказа. Они намеренно пропущены, так как это вопросы бизнеса, а не клиента. Такие операции находятся за рамками процедуры «Прошлые заказы» в качестве клиентского опыта.
Вот еще один пример. Управление меню - это бизнес-возможность (Domain API). Оно включает в себя добавление/удаление пунктов меню в/из ресторанов, регулирование цен на пункты меню и установление ценовых барьеров во избежание убытков.
«Просматривание» ресторанных меню, в то же время, является путешествием клиента (Experience API). Оно включает в себя просмотр ресторанов поблизости, фильтрацию их по категориям, сортировку по рейтингам и популярности.
Теперь давайте посмотрим, как это влияет на архитектуру.
Как Experience API обеспечивают возможность совместного и многократного использования в архитектуре.
В этом разделе мы представляем "Обзор (Browse)" в качестве Experience API для архитектуры и сравниваем его с оркестрацией BFF, рассмотренной ранее.
На этой диаграмме мы сдвигаем усложнение из BFF и переносим его на уровень Experience APIs. Теперь BFF обслуживают потребности конкретных каналов в отличие от оркестрации. Они принимают решения только по тому, что важно для использования, учитывая контекст клиента.
Теперь рассмотрим предыдущий пример с нефункциональной точки зрения. Если оставить BFF для оркестрации вместо Experience API, это означает, что каждый BFF должен будет определить:
Как повторно запустить логику при возникновении тайм-аутов или сбоев.
Как сократить процесс обслуживания, когда другие сервисы неработоспособны.
Например, бизнес может отказаться от показа предложений, если данный сервис неисправен. В этом случае пользователю все равно будет предоставлена возможность полноценного использования функции "Browse" без предложений. Предоставление имплементации этой логики каждому BFF приводит к дублированию и непоследовательной обработке ошибок.
Но в Experience API мы решаем проблемы отказов и повторных попыток в рамках "Browse API". Это позволяет нам обслуживать уменьшенный опыт из единого источника достоверной информации.
Именно такое воплощение клиентского опыта в архитектуре позволяет Experience API стать продуктом, доступным для совместного использования.
Преимущества и последствия использования Experience APIs.
Внедрение Experience API имеет множество каскадных преимуществ. Обсудим их, поскольку они связаны с:
Совокупная стоимость владения.
Масштабирование цифрового присутствия.
Согласование действий команды.
Эволюционная архитектура.
Совокупная стоимость владения:
Предприятия все чаще стремятся предоставлять новые цифровые возможности и подключать новые каналы. Но при этом они испытывают трудности с управлением растущим числом приложений, поддерживающих это.
Аспект Experience APIs "write-once, share-everywhere. Написать один раз, поделиться везде" сокращает время и стоимость разработки, связанные с добавлением новых каналов. Теперь добавление канала требует только создания его собственной логики имплементации. Не нужно заново создавать логику оркестрации.
Масштабирование цифрового присутствия:
Тот же самый аспект "write-once, share-everywhere" также обеспечивает последовательный клиентский опыт во всех каналах. Благодаря этому Experience API повышают скорость выхода на рынок при внедрении новых каналов. По мере того как вся усложненность смещается на уровень опыта, нагрузка на проектирование и разработку канала становится минимальной. За счет такого подхода организации могут масштабировать свое общее цифровое присутствие без особых трудностей.
Согласование действий команды:
Современный цифровой опыт богат и сложен. Тем не менее, организации все еще думают о каналах только как о процессах взаимодействия и не формируют долговременные команды, управляющие каждым уникальным опытом.
Однако клиентский опыт затрагивает различные бизнес-возможности и каналы. Поэтому при изменениях в процессах взаимодействия обычно возникают трения между командами и подразделениями организации.
Если сосредоточить наши команды вокруг клиентского опыта, то все изменения будут осуществляться беспрепятственно. Команды могут независимо работать над своим специфическим опытом, не натыкаясь друг на друга.
Кроме того, команды, ориентированные на опыт, обладают значительной компетенцией в работе с клиентами. Такая клиентоориентированность способствует удовлетворению команды, поскольку четко заметно, как их деятельность непосредственно влияет на клиента. Они в большей степени эмпатичны к основным проблемам клиентов, поскольку находятся рядом с тем, как клиенты взаимодействуют с продуктом.
Эволюционная архитектура:
Experience API — это не подход "все или ничего". Они эволюционны по своей природе. Моделирование такого подхода и структуры команды может быть сначала опробовано для одного опыта, прежде чем его можно будет внедрить в масштабах всей компании.
Experience API также обеспечивают расширяемость архитектуры сервисов. Они не заменяют собой Domain API, а дополняют их. Это обеспечивает столь необходимый слой в архитектуре, который связывает воедино различные точки взаимодействия с клиентами.
Наконец, Experience API дополняют такие паттерны, как Micro Frontends, где команды работают над независимой разработкой и деплоем front-end в большой экосистеме.
Заключительные размышления
Смешение опыта и доменной логики часто приводит к жесткой архитектуре, которая не может развиваться в соответствии с потребностями клиентов.
Хотя это может показаться нелогичным, внедрение новых каналов предполагает акцентирование внимания на клиентском опыте... а не на самих каналах.
Идея, лежащая в основе Experience API, не отличается новизной. Многие сервисы разработаны подобным образом. Хотя их часто называют бизнес-возможностями, за некоторыми исключениями².
Название "Experience APIs" позволяет думать в первую очередь о клиенте и его потребностях. Оно способствует восприятию API как совместно используемых продуктов.
Такое название также помогает отличить настоящую бизнес-возможность от клиентского опыта, поскольку их следует трактовать по-разному.
Из-за того, что эта архитектура зависит от правильной структуры команды, ее трудно реализовать без "перемещения и встряски" организационных границ. Другими словами, здесь, безусловно, необходим обратный маневр Inverse Conway Maneuver. Обратный маневр Конвея - это следствие закона Конвея, который рекомендует формировать командные структуры, приводящие к желаемой архитектуре.
Примечания
¹ Это сокращенный пример. Для реализации полноценного опыта "Browse", вероятно, потребуются другие API, такие как: API Promos, Ratings, Delivery Estimates, Recommendations и др.
² PayPal в своем руководстве по стилю API называет их Experience-based Services and APIs (Сервисы и API, основанные на опыте). Uber называет это Product Layer (уровень продукта), (т.е., Request a Ride. Заказать поездку) в рамках своих 5 уровней архитектуры микросервисов.
Приглашаем всех желающих на бесплатный открытый урок «Как не утонуть в требованиях и понять, какую проблему решаем», на котором поговорим:
— О том, какие виды требований бывают и как они коррелируют между собой.
— Как понять, что заказчик пришел к тебе с реальной проблемой.
— Как отличить проблему, потребность и решение.
Регистрируйтесь по ссылке.
