[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"question-mikroservisy-kakie-printsipy-dekompozitsii-na-mikroservisy-sushchestvuyut":3},{"id":4,"slug":5,"topicId":6,"topicSlug":7,"topicName":8,"topicEmoji":9,"question":10,"answer":11,"codeLang":12,"codeSrc":12,"important":12,"commonMistakes":12,"modernUsage":12,"difficulty":13,"tags":14,"related":16,"progress":17,"seo":18},819,"kakie-printsipy-dekompozitsii-na-mikroservisy-sushchestvuyut",23,"mikroservisy","Микросервисы","🔗","Какие принципы декомпозиции на микросервисы существуют?","Правильная декомпозиция — ключ к успешной микросервисной архитектуре. Она определяет границы сервисов так, чтобы минимизировать связность и максимизировать автономность каждого сервиса.\n\n### 1. Single Responsibility Principle (SRP)\n\nКаждый сервис отвечает за одну бизнес-способность (business capability). Например: сервис платежей, сервис уведомлений, сервис аутентификации.\n\n### 2. Domain-Driven Design (DDD)\n\nДекомпозиция по ограниченным контекстам (Bounded Contexts). Это самый эффективный подход:\n- Проведите Event Storming с бизнес-экспертами\n- Определите домены и поддомены\n- Выделите Bounded Contexts\n- Каждый Bounded Context — кандидат на микросервис\n\n### 3. Высокая связность (High Cohesion)\n\nВсё, что относится к одной бизнес-функции, должно быть в одном сервисе.\n\n### 4. Слабая связанность (Loose Coupling)\n\nИзменение одного сервиса не должно требовать изменения других. Сервисы взаимодействуют только через API.\n\n### 5. Размер команды (правило «двух пицц» Безоса)\n\nОдин сервис должен поддерживаться командой, которую можно накормить двумя пиццами (5-9 человек).\n\n### 6. Декомпозиция по бизнес-подобластям (Subdomains)\n\n- Core domain — конкурентное преимущество (например, скоринговая модель)\n- Supporting subdomain — поддерживающие функции (управление клиентами)\n- Generic subdomain — типовые функции (уведомления, аутентификация)\n\n### Антипаттерны декомпозиции\n\n- Декомпозиция по техническим слоям (сервис для DAO, сервис для бизнес-логики) — это плохо.\n- Слишком мелкие сервисы (nano-сервисы) — чрезмерный overhead.\n- Распределённый монолит — сервисы жёстко связаны и деплоятся вместе.\n\n> **На собеседовании:** самый ценный ответ — DDD и Bounded Context как основа декомпозиции. Обязательно упомяните антипаттерны, особенно «распределённый монолит» — это показывает реальный опыт.","","middle",[15],"microservices",[],null,{"title":19,"description":20,"ogTitle":19,"ogDescription":21,"keywords":22,"schemaAnswer":23,"featuredSnippetReady":24},"Какие принципы декомпозиции на микросервисы существуют? — Gymterview","Правильная декомпозиция — ключ к успешной микросервисной архитектуре. Она определяет границы сервисов так, чтобы минимизировать связность и максимизировать авто","Правильная декомпозиция — ключ к успешной микросервисной архитектуре. Она определяет границы сервисов так, чтобы минимиз",[15,13],"Правильная декомпозиция — ключ к успешной микросервисной архитектуре. Она определяет границы сервисов так, чтобы минимизировать связность и максимизировать автономность каждого сервиса.",true]