How do you define service boundaries using DDD bounded contexts?

Question

Accepted Answer

Good service boundaries follow **business capabilities**, not technical layers. **Domain-Driven Design (DDD)** gives a precise tool for this: the **bounded context** — a boundary within which a domain model and its terms are consistent.

## Bounded context

The word "Customer" can mean different things in different contexts. Each bounded context owns its own model, and a microservice typically maps to one context.

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

## How to find boundaries

- **Align to business capabilities** (Orders, Billing, Shipping), not nouns or DB tables.
- **High cohesion inside, loose coupling across** the boundary.
- Watch where the **ubiquitous language** changes — that's usually a context edge.
- Use a **context map** to document relationships (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
```

If two services constantly call each other to complete one operation, the boundary is probably wrong.

## Why it matters

Boundaries decided early are very expensive to move later, because they harden into APIs and databases that other teams depend on.

DDD bounded contexts give you a principled way to draw those lines along the business, so services stay cohesive and can evolve independently rather than constantly coordinating.