Гранулярность микросервисов: как определить
Практическое руководство по выбору оптимальной гранулярности микросервисов с примерами, сигналами для рефакторинга и чек-листами.
privacy
Эта заметка участвует в semantic memory.
AI Summary
🚀 TL;DR: статья описывает, как правильно нарезать систему на микросервисы, чтобы избежать как излишне крупных, так и излишне мелких сервисов. 🔑 Ключевые факты: 4 принципа идеального микросервиса (единственность ответственности, ограниченный контекст, связанность/связность, принципы проектирования пакетов); 4 принципа баланса (корни агрегации с контекстом видимости, отделение бизнес-логики от данных, anti-corruption layer, BFF по архитектуре фронтенда); сигналы для рефакторинга (повторы в трассировках, нарушение инкапсуляции, дублирование, максимальная сцепленность, линейный рост инфраструктурных работ). 📌 Важные детали: пример системы доставки с 3 типами (курьер, ПВЗ, самовывоз); крупная нарезка приводит к дублированию расчётов и избыточным интерфейсам, мелкая — к over-engineering и росту DevOps-нагрузки; внешние факторы (бюджет, сроки, опыт команды, инфраструктура) влияют на выбор; архитектура изменяема в течение всего жизненного цикла (Эрик Эванс). 💡 Вывод и значение: начинать с определения мастер-данных, ответственности и намерений, внешних факторов; использовать контрольные вопросы для проверки гранулярности; визуализировать архитектуру и проверять coupling/cohesion; планировать эволюцию архитектуры через вихри моделирования (анализ → моделирование → код).