Service decomposition на собеседовании системного аналитика

Подходы

Decomposing monolith в microservices — критическое решение.

Wrong split → distributed monolith, painful.

Right split → independent teams, scale.

По business capability

Capabilities — что business does.

Order Management
Inventory
Shipping
Customer Support
Billing

Each capability — own service / team.

Aligns с organizational structure (Conway's law).

По bounded context

DDD-style. Each context — coherent domain model.

Sales context: Customer (with orders), Order, Product.
Marketing context: Customer (with leads), Campaign.
Support context: Ticket, Customer (with history).

Same concept (Customer) — different model каждом context. OK.

Sizing

«Two-pizza team» rule. Small enough для feed.

Single Responsibility Principle. One service — one focus.

Right size:

• Too small (nano-services). Operational overhead, communication overhead.
• Too big. Loses microservice benefits.

Эмпирика. Service ~3-7 developers, ~10-30k LOC.

Anti-patterns

Distributed monolith. Tightly coupled despite separation.

Shared database. Multiple services same DB.

Sync chains. Long sync RPC chains.

Unclear ownership. Каждый team touches every service.

Big-bang split. Refactor monolith за один раз → catastrophe. Use strangler fig.

Связанные темы

• Микросервисы vs монолит для SA
• Антипаттерны микросервисов для SA
• DDD для SA
• Migration patterns для SA
• Подготовка к собесу системного аналитика

FAQ

Это официальная информация?

Нет. Статья основана на работах Sam Newman, microservices.io.

Тренируйте системный анализ — откройте тренажёр с 1500+ вопросами для собесов.