Какие принципы декомпозиции на микросервисы существуют?

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

1. Single Responsibility Principle (SRP)

Каждый сервис отвечает за одну бизнес-способность (business capability). Например: сервис платежей, сервис уведомлений, сервис аутентификации.

2. Domain-Driven Design (DDD)

Декомпозиция по ограниченным контекстам (Bounded Contexts). Это самый эффективный подход:

• Проведите Event Storming с бизнес-экспертами
• Определите домены и поддомены
• Выделите Bounded Contexts
• Каждый Bounded Context — кандидат на микросервис

3. Высокая связность (High Cohesion)

Всё, что относится к одной бизнес-функции, должно быть в одном сервисе.

4. Слабая связанность (Loose Coupling)

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

5. Размер команды (правило «двух пицц» Безоса)

Один сервис должен поддерживаться командой, которую можно накормить двумя пиццами (5-9 человек).

6. Декомпозиция по бизнес-подобластям (Subdomains)

• Core domain — конкурентное преимущество (например, скоринговая модель)
• Supporting subdomain — поддерживающие функции (управление клиентами)
• Generic subdomain — типовые функции (уведомления, аутентификация)

Антипаттерны декомпозиции

• Декомпозиция по техническим слоям (сервис для DAO, сервис для бизнес-логики) — это плохо.
• Слишком мелкие сервисы (nano-сервисы) — чрезмерный overhead.
• Распределённый монолит — сервисы жёстко связаны и деплоятся вместе.

На собеседовании: самый ценный ответ — DDD и Bounded Context как основа декомпозиции. Обязательно упомяните антипаттерны, особенно «распределённый монолит» — это показывает реальный опыт.