Определение доменной области
Теперь, когда сложилось общее представление о паттерне Strangler Fig, перейдём к деталям и техникам.
Первый шаг паттерна носит, скорее, стратегический характер: нужно решить, что и когда будет извлекаться из монолита. Команда сначала определяет список потенциальных функций продукта, а затем приоритет и возможность их извлечения. Ответы на эти вопросы стоит искать в технических показателях, отзывах клиентов, маркетинговых исследованиях и бизнес-аналитике.
Определить важность каждой функции можно, учитывая потребности клиентов, болевые точки и потенциальное влияние на удовлетворённость клиентов или бизнес-цели. А оценить осуществимость каждой функции — принимая во внимание техническую сложность, трудоёмкость разработки и ограниченность ресурсов.
Техника 1. Анализ домена бизнеса, Domain-Driven Design
Domain-Driven Design (DDD) — методология разработки ПО, основанная на тесном взаимодействии бизнеса и разработчиков. Основной принцип этой техники — разделение приложения на домены, которые представляют собой ограниченный контекст бизнес-проблем и целей.
Каждый такой ограниченный контекст — бизнес-домен — может рассматриваться для выделения в качестве независимого микросервиса. Команда разработчиков вместе с бизнес-аналитиками определяет компоненты, которые имеют наибольшую ценность для бизнеса, и затем соответствующие границы в рамках монолитного приложения.
В каких случаях применяется Domain-Driven Design?
Domain-Driven Design полезен, когда монолитное приложение содержит сложную бизнес-логику и поддерживается крупными командами. Чтобы вести и развивать такой проект, требуется чёткое разделение обязанностей. Этот подход помогает структурировать код так, чтобы он лучше отражал бизнес-процессы и был проще в сопровождении и развитии.
Техника 2. Технический анализ
В отличие от бизнес-ориентированного подхода DDD, этот подход «смотрит» внутрь приложения.
При техническом анализе оценивается монолитная кодовая база на предмет тесно связанных компонентов, зависимостей и взаимодействия модулей. При этом подходе важно определить части кода, которые часто меняются или которые сложно поддерживать. Они и будут основными кандидатами на извлечение.
В каких случаях применяется технический анализ?
Лучше всего этот подход использовать в унаследованных системах, где кодовая база сложна и плохо документирована. Технический анализ может выявить скрытые зависимости и взаимодействия, которые не видны только при бизнес-анализе.
Ещё технический анализ незаменим в тех случаях, когда монолитное приложение имеет большой технический долг: в нём много областей, которые часто требуют обслуживания или подвержены ошибкам и проблемам с производительностью. С его помощью выявляются компоненты, которые нуждаются в рефакторинге или оптимизации в виде микросервисов.
Техника 3. Анализ производительности
Название этой техники говорящее: здесь важно сосредоточиться на компонентах, вызывающих проблемы с производительностью или требующих больших ресурсов.
Чтобы выявить компоненты, которые требуют оптимизации и модернизации в первую очередь, определяются наиболее используемые функции на основе шаблонов взаимодействия с пользователями.
В каких случаях применяется?
Анализ производительности применяется прежде всего в приложениях, которым необходимо эффективное масштабирование. Показатели производительности позволяют определить, какие составляющие ограничивают масштабируемость и должны быть приоритетными для миграции.
Этот метод используется, когда плохая производительность напрямую влияет на пользователей. Например, медленное время отклика или частые перебои в работе.
Для организаций, которые предпочитают принимать решения на основе количественных данных, этот метод подходит идеально. Показатели производительности дают чёткое представление о том, где кроются проблемы.
Как решить, какую технику использовать?
- Если согласование переноса с бизнес-целями и максимизация непосредственной ценности для бизнеса имеют решающее значение, выберите в качестве приоритета анализ бизнес-домена.
- Для унаследованных систем с большим техническим долгом и сложной, запутанной кодовой базой технический анализ даст более глубокое понимание необходимых усилий по рефакторингу и устранению противоречий.
- Если основные проблемы связаны с масштабируемостью и производительностью и они влияют на пользовательский опыт, сосредоточьтесь на показателях производительности, чтобы определить приоритеты.
Во многих случаях наиболее эффективным будет сочетание этих методов.
Задание 1
Соотнесите техники анализа с их описаниями.
Приоритизация функций
Представьте: команда использовала все три техники и в результате получила семь функций монолитного приложения, которые можно или нужно извлекать. А как выбрать, какие части извлечь сначала, а какие потом? Для этих целей понадобятся различные техники расстановки приоритетов, в том числе из области менеджмента.
Учёт технического, делового и клиентского влияния
На этом этапе нужно оценить техническую сложность и усилия, необходимые для разработки каждой функции. Проанализировать, есть ли квалифицированные разработчики для реализации миграции, совместима ли миграция с существующими технологиями и каково потенциальное влияние на производительность продукта.
Упрощённо формула принятия решения выглядит так:
Отдавайте предпочтение тем функциям, которые обеспечивают высокую ценность при относительно небольших технических затратах.
Для ранжирования компонентов важно учитывать именно соотношение трёх уже известных факторов — бизнес-целей, технических возможностей и интересов клиентов.
- Бизнес-влияние: рассмотрите влияние каждой функции на бизнес, например, её потенциал для получения прибыли, удержания клиентов или конкурентного преимущества. Согласуйте приоритетность функций с общими бизнес-целями и стратегией.
- Техническое влияние: проведите анализ зависимостей между компонентами, чтобы выделить те, которые можно изолировать и вынести в микросервисы без значительных изменений других частей системы. Оцените масштабируемость и производительность новой архитектуры. Выберите подходящие инструменты и технологии для каждого микросервиса и учтите необходимость эффективного тестирования и мониторинга всей системы.
- Клиентское влияние: учтите отзывы, предпочтения и болевые точки клиентов. Сосредоточьтесь на функциях, которые удовлетворяют самые насущные потребности вашей целевой аудитории и способствуют положительному пользовательскому опыту.
Задание 3
Команда разработчиков продукта определяет приоритетность функций. Соотнесите следующие факторы с влиянием, которое они оказывают.
Потенциал функции для получения повторяющегося дохода
Бизнес-влияние
Потенциал функции для получения повторяющегося дохода является примером влияния на бизнес.
Отзывы клиентов, требующих добавления конкретной функции
Влияние на клиента
Отзывы клиентов, требующих добавления конкретной функции, указывают на то, что функция учитывает предпочтения и болевые точки клиента.
Возможность реализовать функцию с минимальным влиянием на производительность системы
Техническое влияние
Это соображение, связанное с технической сложностью и усилиями по разработке.
Теперь давайте взглянем, как онлайн-магазин «Шайба» применил все эти методы и определил компоненты — кандидатов на выделение из монолитного приложения.
1. Анализ бизнес-домена (Domain-Driven Design)
- Каталог продукции: все аспекты, связанные со списком товаров, их описанием, ценообразованием и состоянием запасов.
- Управление пользователями: управление регистрацией, аутентификацией, профилями и предпочтениями пользователей.
- Обработка заказов: управление всем жизненным циклом заказа, включая управление корзиной, оформление заказа, обработку платежей и выполнение заказа.
- Поддержка клиентов: управление запросами клиентов, тикетами поддержки и каналами связи.
- Маркетинг и рекламные акции: управление маркетинговыми кампаниями, рекламными предложениями и скидками.
- Аналитика и отчётность: сбор и анализ данных о поведении пользователей, продажах и других ключевых показателях для создания отчётов и аналитических материалов.
2. Технический анализ
- Управление запасами. Технический анализ выявляет тесно связанный код и значительные зависимости с каталогом товаров. Эти зависимости требуют тщательного разделения.
- Платёжный шлюз. Этот компонент глубоко интегрирован в систему обработки заказов. Технический анализ показывает сложное взаимодействие с различными поставщиками платежей, что требует выделения отдельного микросервиса.
- Recommendation Engine: В настоящее время сервис встроен в каталог товаров, но рекомендуется выделить в отдельный сервис из-за специализированных алгоритмов и требований к обработке данных.
3. Показатели производительности
- Процесс оформления заказа. Показатели производительности свидетельствуют о том, что процесс оформления заказа является узким местом: время отклика в периоды пикового трафика слишком высокое.
- Функциональность поиска. Частые жалобы пользователей на медленную и зачастую нерелевантную выдачу результатов указывают на необходимость оптимизации этого компонента.
- Отслеживание активности пользователей. Высокое потребление ресурсов для отслеживания активности пользователей и создания аналитических отчётов говорит о необходимости специализированного сервиса для эффективной обработки этой нагрузки.
Методы расстановки приоритетов
Методов расстановки приоритетов существует множество, и вы наверняка уже используете какие-то из них в своей жизни. Мы рассмотрим на примере пару самых используемых, а об остальных вы сможете почитать в дополнительных материалах.
MoSCoW
Метод приоритизации MoSCoW разделяет требования на четыре категории: Must have (обязательно), Should have (нужно), Could have (желательно) и Won't have (можно перенести). Это помогает определить самые критически важные функции проекта и сосредоточиться на них. Однако он может быть менее эффективным, если команда с трудом различает функции «обязательно» и «нужно».
Когда использовать метод MoSCoW эффективно?
- У проекта есть чётко определённые бизнес-цели, и необходимо тесно увязать технические задачи с приоритетами бизнеса. Метод MoSCoW помогает убедиться, что наиболее важные бизнес-функции будут рассмотрены в первую очередь.
- Когда в процесс вовлечено множество заинтересованных сторон и их согласие крайне важно. Метод MoSCoW способствует обсуждению того, что необходимо (Must have), а что может быть отложено (Should have, Could have).
- При управлении ограниченными ресурсами (время, бюджет, персонал) и необходимости расставлять приоритеты в задачах, чтобы наилучшим образом использовать имеющиеся ресурсы.
Проранжировав компоненты по методу MoSCoW, команда «Шайбы» разделила функции следующим образом:
- Must (обязательно)
- Обработка заказов. Этот компонент очень важен, поскольку он обеспечивает весь жизненный цикл заказа, включая управление корзиной, оформление заказа, обработку платежей и выполнение заказа. Любой сбой в работе этого сервиса напрямую влияет на продажи и удовлетворённость клиентов.
- Каталог продукции. Эта служба, являющаяся основой платформы электронной коммерции, отвечает за списки товаров, их описания, цены и состояние запасов. Точное и эффективное управление каталогом товаров необходимо для обслуживания клиентов и осуществления продаж.
- Процесс оформления заказа. Оптимизация процесса оформления заказа, признанного «узким местом», имеет решающее значение для повышения качества обслуживания пользователей и снижения числа отказов от корзины.
- Should (нужно)
- Управление пользователями. Управление регистрацией, аутентификацией, профилями и предпочтениями пользователей необходимы для персонализированного взаимодействия с клиентами и обеспечения безопасности. Но на начальных этапах миграции эти функции могут временно реализовываться в существующей системе.
- Платёжный шлюз. Обеспечивает взаимодействие с поставщиками платежей. Хотя он очень важен для обеспечения безопасности транзакций, им можно временно управлять через монолит, если приоритет отдаётся сервису обработки заказов.
- Could (желательно)
- Recommendation Engine. Улучшает пользовательский опыт, предоставляя персонализированные рекомендации по товарам. Ценен для повышения продаж и вовлечённости, но не критичен для основной работы.
- Поддержка клиентов важна для удовлетворения потребностей клиентов, но имеет приоритет ниже по сравнению с услугами, связанными с продажами.
- Маркетинг и рекламные акции. Этот компонент управляет маркетинговыми кампаниями и рекламными предложениями, имеет большое значение, но может быть реализован на более поздних этапах после переноса основных функций.
- Won’t Have this time (можно перенести)
- Аналитика и отчётность. Хотя этот компонент важен для понимания бизнеса, его можно использовать с помощью существующих монолитных систем до тех пор, пока основные функции, ориентированные на клиентов, не будут перенесены и стабилизированы.
Матрица Эйзенхауэра
Матрица Эйзенхауэра — это инструмент управления временем, который помогает расставить приоритеты задач, разделяя их на четыре категории: срочные и важные, важные, но не срочные, срочные, но не важные, не срочные и не важные. Однако этот метод может не подойти для сложных проектов.
Когда использовать матрицу Эйзенхауэра эффективно?
- Если при расстановке приоритетов необходимо учитывать срочность задач. Матрица Эйзенхауэра полезна для балансировки между задачами, требующими немедленного внимания, и теми, которые важны, но менее срочны.
- В сценариях, где быстрое принятие решений имеет решающее значение, например при устранении узких мест в производительности или перебоев в работе системы, которые влияют на работу пользователей.
- При определении приоритетов повседневных задач, которые требуют чёткого разграничения между срочными задачами, требующими немедленных действий, и теми, которые можно запланировать на более поздний срок.
Пример. Если применить матрицу Эйзенхауэра к онлайн-магазину «Шайба», то список будет выглядеть похожим, но мотивационные факторы отличаются.
Срочные и важные:
- Обработка заказов. Этот компонент критически важен для обработки операций по продажам, которые напрямую влияют на доход и удовлетворённость клиентов. Любые проблемы здесь требуют немедленного решения.
- Каталог продукции. Каталог товаров, необходимый для отображения товаров покупателям, напрямую влияет на удобство работы пользователей и продажи. Необходимо принять срочные меры для обеспечения его функциональности.
- Процесс оформления заказа. Оптимизация процесса оформления заказа, признанного «узким местом», имеет решающее значение для сокращения числа брошенных корзин и повышения коэффициента конверсии продаж.
Не срочно, но важно:
- Управление пользователями. Несмотря на то что эта функция не является критически важной, она важна для общей безопасности и персонализации платформы.
- Платёжный шлюз. Эта функция обеспечивает безопасную обработку транзакций. Несмотря на то что она очень важна для работы, платежами можно временно управлять через монолит, пока не стабилизируются другие критические компоненты.
- Recommendation Engine. Функция нужна для улучшения пользовательского опыта и повышения продаж за счёт персонализированных рекомендаций. Важна для долгосрочного привлечения пользователей, но не требует немедленного решения.
- Поддержка клиентов. Управление запросами клиентов и тикетами поддержки важно для удовлетворённости клиентов, но эта функция может быть отложена до переноса основных функций, связанных с продажами.
Срочно, но не важно:
- Маркетинг и рекламные акции. Маркетинговые кампании, рекламные предложения и управление скидками актуальны для повышения продаж и вовлечённости, но менее важны, чем основные функции, такие как обработка заказов и управление пользователями.
Не срочные и не важные:
- Аналитика и отчётность. Эти функции обеспечивают понимание бизнеса, но пока могут быть реализованы с помощью существующих систем. Их миграцию можно отложить до тех пор, пока основные функциональные возможности не будут полностью перенесены и стабильны.
Как видно, методы дают схожие результаты, но предпосылки их использования немного разные.
Можно применять и оба метода: например, на этапе стратегического планирования расставлять приоритеты методом MoSCoW, а затем в процессе повседневных задач использовать матрицу Эйзенхауэра.
Задание 4
Соотнесите следующие ситуации с подходящими методами приоритизации (MoSCoW или матрица Эйзенхауэра).
Ещё методы приоритизации
Вы можете изучить и другие методы для ранжирования функций по степени важности и целесообразности.
- Модель Кано — это метод приоритизации, ориентированный на клиента. Модель Кано разделяет функции на пять типов в зависимости от их влияния на удовлетворённость клиентов: Must-Have, Performance, Excitement, Indifferent и Reverse.
Она помогает командам определить функции, которые могут создать конкурентное преимущество. Однако она может потребовать больше времени и усилий для сбора отзывов клиентов по каждой функции и может быть субъективной по своей природе. - Модель взвешенного оценивания (Weighted Scoring Model). Этот метод присваивает вес каждой функции на основе таких факторов, как потребительская ценность, влияние на бизнес и техническая осуществимость. Затем функции ранжируются по их общему взвешенному баллу.
Этот метод обеспечивает структурированный подход к расстановке приоритетов, но может занять много времени и быть предвзятым, если весовые коэффициенты не будут тщательно продуманы. - ICE Scoring — это простая и эффективная система расстановки приоритетов, которая помогает командам оценивать и определять приоритеты задач, проектов или функций на основе трёх ключевых критериев: Воздействие, Уверенность и Усилия (Impact, Confidence, and Effort, ICE). Каждый критерий оценивается по заранее определённой шкале, а полученные баллы объединяются для получения чёткого рейтинга приоритетов.
- Value vs. Effort. Этот метод предполагает нанесение характеристик на график, где одна ось представляет ценность для клиентов, а другая — усилия, необходимые для реализации характеристики. Такой подход помогает командам сосредоточиться на функциях, имеющих высокую ценность и не требующих больших затрат. Однако точная количественная оценка ценности и усилий может быть затруднена.
- Cost of Delay (CoD) — это система расстановки приоритетов, которая помогает бизнесу количественно оценить экономическую ценность более раннего достижения конкретной цели по сравнению с более поздним. Однако этот метод может не подходить для проектов, в которых финансовое воздействие не является первостепенной задачей, а также требует точной оценки затрат и выгод.
Итоги
В этом уроке вы рассмотрели техники, с помощью которых можно выделить компоненты в монолите.
- Domain-Driven Design (DDD) помогает разделить приложение на домены, облегчая взаимодействие бизнеса и разработчиков.
- Технический анализ изучает внутреннюю структуру монолита, выявляя связанные компоненты и зависимости, полезен для систем с большим техническим долгом.
- Анализ производительности фокусируется на компонентах, влияющих на масштабируемость и производительность.
Вы разобрали основные методы ранжирования этих компонентов для процесса миграции. Каждый метод расстановки приоритетов имеет свои плюсы и минусы, поэтому важно выбрать тот, который лучше всего соответствует потребностям и контексту вашей команды.