¿Cómo defines los límites del servicio utilizando DDD bounded contexts?

Question

Accepted Answer

Los buenos límites de servicio siguen **capacidades empresariales**, no capas técnicas. **Domain-Driven Design (DDD)** proporciona una herramienta precisa: el **bounded context** — un límite dentro del cual un modelo de dominio y sus términos son consistentes.

## Bounded context

La palabra "Customer" puede significar cosas diferentes en diferentes contextos. Cada bounded context posee su propio modelo, y un microservice generalmente se asigna a un contexto.

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

## Cómo encontrar límites

- **Alinear con capacidades empresariales** (Orders, Billing, Shipping), no sustantivos o tablas de BD.
- **Alta cohesión dentro, acoplamiento suelto a través del** límite.
- Observa dónde cambia el **ubiquitous language** — eso es generalmente un borde de contexto.
- Usa un **context map** para documentar relaciones (upstream/downstream).

## Anti-patterns

```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
```

Si dos servicios se llaman constantemente el uno al otro para completar una operación, el límite probablemente sea incorrecto.

## Por qué es importante

Los límites decididos tempranamente son muy caros de mover después, porque se endurecen en APIs y bases de datos en las que otros equipos dependen.

DDD bounded contexts te brinda una forma principiada de trazar esas líneas a lo largo del negocio, para que los servicios permanezcan cohesivos y puedan evolucionar independientemente en lugar de coordinarse constantemente.