Методология SEED(S) для проектирования микросервисов

В статье автор исследует методологию SEED(S), которая предназначена для проектирования микросервисной архитектуры. Применение методологии позволяет ориентироваться на пользователя и помогает минимизировать количество ошибок.

Ключевые слова: API, микросервисная архитектура, SEED(S), проектирование микросервисов.

Микросервисная архитектура — это стиль проектирования, который структурирует систему приложения как набор сервисов [3].

Для реализации приложения на основе микросервисной архитектуры методология SEED(S), которая представляет собой семь основных этапов эволюционного проектирования (Seven Essential Evolutions of Design for Services), на рис. 1 изображена контекстная диаграмма методологии в нотации IDEF0.

Рис. 1. Контекстная диаграмма проектирование микросервисов [2, 4]

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

Далее мы рассмотрим методологию с точки зрения проектирования, а значит только первые шесть шагов методологии на рис. 2.

Рис. 2. Декомпозиция проектирование микросервисов [2, 4]

Идентификация участников представляет собой шаг, направленный на выявление всех заинтересованных сторон, которые будут пользоваться разрабатываемой системой микросервисов. Каждый участник выступает в роли собирательного образа, цель при определении участника — описать участника таким образом, чтобы была возможность категоризировать пользователей системы и в дальнейшем построить шаблоны взаимодействия с разрабатываемой системой. Поэтому стоит избегать слишком широких определений участников, но при этом чем меньше участников, тем лучше. Корректная и полная идентификация участников на этом этапе закладывает фундамент для глубокого понимания потребностей и ожиданий от разрабатываемой системы, что имеет критическое значение для успешного проектирования микросервисной архитектуры.

Определение заданий участников — этот этап посвящен анализу основных задач, которые будут решать участники. Для проектирования системы нам необходимо воспринимать микросервисы и API как продукты, которые призваны удовлетворять потребности пользователей. Поэтому нам понадобятся сценарии использования этих продуктов для каждого идентифицированного участника. Для того, чтобы зафиксировать задания участников, используется концепция Jobs to be Done (JTBD), которая и позволяет описать контекст, мотивацию и ожидаемый результат каждого действия. В подходе JTBD в центре изучения находится не пользователь, а необходимая ему работа для выполнения, которая позволит ему достичь желаемых изменений (прогресса) при заданных обстоятельствах (контексте) [1]. Этот подход обеспечивает более глубокое понимание реальных потребностей пользователей и помогает избежать излишнего акцента на технических деталях реализации. Результатом данного этапа является формирование перечня действий и задач, выполняемых различными участниками в контексте разрабатываемой системы, что служит основой для дальнейшего проектирования и разработки сервиса.

Выявление шаблонов взаимодействия — предполагает анализ и моделирование типовых последовательностей действий и обменов данными между участниками и системой. На этом этапе уже формируются границы микросервисов и визуализируются через шаблоны взаимодействия в виде диаграмм последовательностей Unified Modeling Language (UML). Цель на данном этапе отразить как пользовательские требования преобразуются во взаимодействия между сервисами на техническом уровне. Выполнив моделирование на этом этапе, мы сможем зафиксировать технические требования к микросервису или API в виде набора действий и запросов.

Выделение действий и запросов из JTBD — результатом данного этапа является четко описанные техническим языком шаблоны запросов и действий, которые лягут в основу проектирования API и функциональности отдельных микросервисов.

Описание каждого запроса и действия в виде спецификации, шаг, направленный на формализацию и стандартизацию интерфейсов взаимодействия между компонентами микросервисной архитектуры. Данный шаг предполагает использование OpenAPI Specification (OAS) — формализованного стандарта для описания REST API сервисов. OAS позволяет определить структуру и поведение API независимо от языка программирования или технологической платформы, что обеспечивает универсальность и гибкость при интеграции различных компонентов системы. Результатом данного этапа является набор спецификаций OpenAPI для каждого микросервиса.

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

Заключительным этапом является непосредственная реализация микросервисов, включающая разработку, тестирование и развертывание программного кода [2].

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

Литература:

1. Васильева, Е. В. Методологии проектирования стратегии бизнеса: от дизайна продукта к проектированию платформ / Е. В. Васильева // Управление. — 2021. — Т. 9, № 2. — С. 76–89.
2. Митра, Р. Микросервисы. От архитектуры до релиза. / Р. Митра, И. Надареишвили. — СПб: Питер, 2023. — 336 c. — Текст: непосредственный.
3. Ричардсон, К. Микросервисы. Паттерны разработки и рефакторинга. / К. Ричардсон. — СПб: Питер, 2020. — 544 c. — Текст: непосредственный.
4. Нотация IDEF0. — Текст: электронный // businessstudio: [сайт]. — URL:https://www.businessstudio.ru/wiki/docs/current/doku.php/ru/csdesign/bpmodeling/idef0 (дата обращения: 24.12.2024).