Паттерны микросерверной разработки: декомпозиция

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

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

Decompose By Business Capability

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

Вот как может выглядеть создание микросервисов на основе вышеописанного паттерна для интернет-магазина:

Decompose By Subdomain

Следующий паттерн -- шаблон «Разбиение по поддоменам». В случае разбиения по бизнес-возможностям иногда появляются так называемые God Classes -- «божественные классы» — то есть сущности, которые являются общими для нескольких микросервисов. И обычно эти классы трудно разделить.

Допустим, в том же интернет-магазине проблемной сущностью может стать заказ. В вышеприведенном примере он применяется в нескольких сервисах: - Orders Creation, - Orders Delivery, - Orders Alerts, - Preorders.

Во избежание возникновения God Classes мы можем задействовать альтернативный шаблон разложения на микросервисы — Decompose By Subdomain. Этот шаблон основывается на концепциях DDD (Domain-Driven Design, то есть предметно-ориентированное проектирование).

DDD позволяет разбивать всю модель предметной области (то есть домен) на поддомены. То есть у каждого поддомена существует своя модель данных, а область действия этих данных называют ограниченным контекстом -- Bounded Context. Таким образом, каждый микросервис разрабатывается внутри этого ограниченного контекста. Главная задача при таком подходе — подобрать поддомены, а также границы между ними таким образом, чтобы они были максимально независимыми друг от друга.

Возвращаемся к интернет-магазину. Все, что связано с заказами, мы можем рассмотреть в рамках соответствующего поддомена «Заказы» (Orders Subdomain). И уже внутри этого поддомена создается микросервис для управления заказами (Orders Service). Профит -- появляется возможность уменьшить количество микросервисов, если сравнивать с той же декомпозицией на основании бизнес-возможностей. Ниже -- сильно упрощенный пример, где 4 микросервиса преобразованы в один:

По материалам блога https://mcs.mail.ru/blog/.