Как вы определяете границы сервисов, используя DDD bounded contexts?

Question

Accepted Answer

Хорошие границы сервисов следуют **бизнес-возможностям**, а не техническим слоям. **Domain-Driven Design (DDD)** предоставляет для этого точный инструмент: **bounded context** — граница, в которой модель домена и её термины согласованы.

## Bounded context

Слово "Customer" может иметь разные значения в разных контекстах. Каждый bounded context владеет своей моделью, а микросервис обычно соответствует одному контексту.

```text
┌───────────────────┐   ┌────────────────────┐
│  Sales context    │   │  Support context   │
│  Customer =       │   │  Customer =        │
│   leads, orders   │   │   tickets, SLAs    │
└───────────────────┘   └────────────────────┘
   one service             another service
```

## Как найти границы

- **Выравнивайте по бизнес-возможностям** (Orders, Billing, Shipping), а не по существительным или таблицам БД.
- **Высокая связность внутри, слабая связь поперек** границы.
- Следите, где меняется **ubiquitous language** — обычно это край контекста.
- Используйте **context map** для документирования отношений (upstream/downstream).

## Антипаттерны

```text
✗ Entity services ("User service", "Product service") — too fine, chatty
✗ Splitting by technical layer (a "database service")
✗ Boundaries that force a distributed transaction for every operation
```

Если два сервиса постоянно вызывают друг друга для завершения одной операции, граница вероятно неправильна.

## Почему это важно

Границы, определённые на ранних этапах, очень дорого переносить позже, потому что они затвердевают в API и базах данных, от которых зависят другие команды.

DDD bounded contexts дают вам принципиальный способ провести эти линии по линии бизнеса, так чтобы сервисы оставались когезивными и могли эволюционировать независимо, вместо постоянной координации.