🗺️ 5 подходов к определению границ микросервисов 🗺️

Хорошая декомпозиция системы на микросервисы — это когда по каждому сервису понятно:
✔️ чем владеет (данные),
✔️ какие функции выполняет,
✔️ что он гарантирует (SLA),
✔️ и как реагирует на сбои.

Разберём 5 ключевых подходов к декомпозиции системы на микросервисы на примере проекта по управлению рекламой #AdFlowGA👇


———

1️⃣ По группам функций

Каждый микросервис объединяет логически связанные функции.

🔹 Сервис объявлений
Создание и редактирование креативов, версии, черновики, статусы.

🔹 ERID-сервис
Интеграция с ОРД, регистрация рекламы, хранение ERID, ретраи при ошибках.

🔹 Управление публикациями
Интеграции с рекламными API (VK, Telegram и др.), получение platformAdId.

🔹 Сервис биллинга
Резерв бюджета, списания, учёт показов, финансовая отчётность.

Подход понятный.
Но может игнорировать реальные доменные границы и различия в SLA.

———


2️⃣ По доменам (DDD — Bounded Context)

Выделяем ограниченные контексты с собственными правилами и моделями данных.

🔹 Домен “Управление объявлениями”
Креативы, статусы, версии, бизнес-правила переходов состояний.

🔹 Домен “Маркировка”
ERID, интеграция с ОРД, требования к отчётности, юридические ограничения.

🔹 Домен “Публикация”
Работа с API площадок, синхронизация статусов, дедупликация запросов.

🔹 Домен “Финансы”
Резервы, списания, корректировки, возвраты.

Важно:
разные домены = разные SLA и разные требования к отказоустойчивости.


———

3️⃣ По данным (Data Ownership)

Каждый сервис владеет своим набором сущностей.

🔹 Управление объявлениями
Ad, AdVersion, AdStatus.

🔹 Биллинг
Budget, Reservation, Transaction.

🔹 Публикации
PlatformAd, SyncStatus.

Никакой “общей БД на всех”.
Данные связаны по id (PK - первичным ключам).
Связь через брокеры + API.


———

4️⃣ По процессным границам

Границы сервисов можно выявить через группы сценариев, которые логически связаны и часто изменяются вместе.

🔹 Запуск рекламной кампании
Создание объявления, прохождение модерации, получение ERID, публикация на площадке, активация, запуск биллинга.

🔹 Управление кампанией
Приостановка и возобновление показов, изменение статуса, обновление параметров размещения.

🔹 Управление бюджетом
Начисление бюджета, резерв средств, списание, корректировки, возвраты.


———

5️⃣ По уровню нагрузки и SLA

Это уже архитектурная зрелость.

🔹 Сервис статистики
Высокая нагрузка на чтение, горизонтальное масштабирование.

🔹 Сервис публикаций
Много внешних API-вызовов, таймауты и задержки.

🔹 Биллинг
Повышенные требования к консистентности и надёжности.


———

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


👉 Разные способы декомпозиции часто приводят к похожему набору сервисов.

Но основание для выделения сервиса должно быть зафиксировано в архитектурных принципах проекта.

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


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