Вопрос проверяет понимание принципов декомпозиции системы и знания базовых идей доменной и архитектурной архитектуры.
Систему делят на микросервисы по бизнес-функциям, а не по техническим слоям. Каждый сервис должен быть слабо связан с другими и иметь чёткие границы ответственности. Часто используют идеи из Domain-Driven Design. Главная цель — снизить связанность и повысить автономность команд.
Разделение системы на микросервисы — это сложная архитектурная задача, а не механическое дробление кода.
Перед разделением важно понять, какие бизнес-задачи решает система.
Разделение по бизнес-возможностям
сервис отражает конкретную бизнес-функцию
изменения в бизнес-логике локализованы
Bounded Context
каждый сервис имеет собственный контекст
одинаковые термины могут иметь разный смысл в разных сервисах
минимизация пересечений логики
Слабая связанность достигается за счёт:
взаимодействия через API
отсутствия общих баз данных
минимального знания о внутренней реализации других сервисов
Внутри одного микросервиса:
логика тесно связана
компоненты работают на одну цель
изменения редко затрагивают другие сервисы
Хорошая декомпозиция строится вокруг бизнеса, а не технологий. Это упрощает развитие системы и масштабирование команд.
