🔎 5 способов выделения микросервисов 🔎

Микросервисы (МС) — это способ разбить большую систему на независимые, слабо связанные компоненты, каждый из которых отвечает имеет свою функциональную зону ответственности и релизится/масштабируется отдельно.

Другими словами — это небольшие сервер-приложения с их собственными БД.


Ниже — 5 ключевых подходов к декомпозиции сложной системы на микросервисы на примере проекта по доставке еды из ресторанов #FoodDeliveryGA 👇

-----------

1️⃣ По группам функций
Каждый МС объединяет логически связанные функции.

🔹 Управление пользователями
Регистрация, управление профилем, настройка избранных адресов доставки, настройки уведомлений.

🔹 Ведение справочника ресторанов
Управление ресторанами, статусом “онлайн/офлайн”, графиком работы, зонами доставки.

🔹 Ведение меню
Управление блюдами, модификаторами (доп.сыр, острый соус и др), размерами порций, доступностью позиций.

🔹 Работа с заказами
Создание заказа, статусы (принят, готовится, в доставке, доставлен, отменён), история заказов.

🔹 Доставка заказа
Назначение курьера, статусы (свободен, едет в ресторан, везёт заказ), геолокация.

🔹 Оплата заказа
Онлайн-оплата, статусы транзакций, возвраты, фискальные чеки, отчётность.

🔹 Рассылка уведомлений
Push/SMS/email-уведомления пользователям, ресторанам и курьерам по ключевым событиям.

-----------

2️⃣ По доменам (DDD - Domain Driven Design)
Выделяем bounded contexts (ограниченные контексты) по предметным областям.

🔹 Домен “Заказы”
Формирование заказов, статусы, бизнес-правила (минимальная сумма, время закрытия кухни, ограничения по району).

🔹 Домен “Рестораны и меню”:
Справочник ресторанов, витрина меню, управление доступностью блюд.

🔹 Домен “Логистика”
Маршрутизация курьеров, расчёт времени доставки, распределение заказов между курьерскими службами.

🔹 Домен “Платежи”
Интеграции с платёжными провайдерами, авторизация/списание, возвраты, финансы и отчёты.

🔹 Домен “Пользователи”
Профили, адреса, история заказов, избранные рестораны и блюда.

🔹 Домен “Лояльность”
Управление скидками, акциями и промокодами.

-----------

3️⃣ По данным
Каждый МС управляет узким набором сущностей.

🔹 Пользователи:
телефоны/email, избранные адреса, предпочтения.

🔹 Заказы:
состав заказа (позиции + модификаторы), суммы, статусы, временные метки.

🔹 Платежи:
транзакции, статусы оплат, идентификаторы операций у платёжных провайдеров.

-----------

4️⃣ По пользовательским сценариям
МС обслуживает конкретный Use Case.

🔹 Оформление заказа
Поиск ресторана, выбор блюд и модификаторов, расчёт стоимости, применение промокодов, выбор способа оплаты.

🔹 Приём и обработка заказа рестораном
Подтверждение/отмена, учёт закрытой кухни, недоступности блюд, времени готовки.

🔹 Доставка
Назначение курьера, трекинг заказа на карте, смена статусов, уведомления пользователю.

🔹 Поддержка
Обработка обращений: заказ опоздал, блюдо не привезли, неверный чек и т.д.

-----------

5️⃣ По уровню нагрузки
Высоконагруженные и обычные части системы выделяются в отдельные сервисы со своими SLA и требованиями к масштабируемости.

🔹 Каталог ресторанов и меню
Массовые чтения (поиск, фильтры, рекомендации), особенно в пиковые часы (обед, вечер, пятница).

🔹 Создание и трекинг заказов
Постоянные изменения статусов, обновления на экране пользователя в реальном времени.

🔹 Логистика/геолокация
Много запросов на обновление координат курьеров и расчёт ETA.

🔹 Платежи
Пиковые нагрузки при акциях и распродажах, повышенные требования к отказоустойчивости.

-----------

Список микросервисов по каждой категории можно продолжить.

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

👉 Сочетайте способы декомпозиции и фиксируйте принципы выделения новых микросервисов в архитектурной документации проекта.

Это поможет избежать неясностей и обеспечит гибкость при развитии проекта 🚀


#АрхитектураGA