DDD bounded context를 사용해 서비스 경계를 어떻게 정의하나요?

Question

Accepted Answer

좋은 서비스 경계는 기술 계층이 아니라 **비즈니스 기능**을 따릅니다. **DDD(Domain-Driven Design, 도메인 주도 설계)**는 이를 위한 정밀한 도구인 **bounded context(경계 컨텍스트)**를 제공합니다. 이는 도메인 모델과 그 용어가 일관되게 유지되는 경계입니다.

## Bounded context

"Customer"라는 단어는 컨텍스트마다 다른 것을 의미할 수 있습니다. 각 bounded context는 자체 모델을 소유하며, 마이크로서비스는 일반적으로 하나의 컨텍스트에 매핑됩니다.

```text
┌───────────────────┐   ┌────────────────────┐
│  Sales context    │   │  Support context   │
│  Customer =       │   │  Customer =        │
│   leads, orders   │   │   tickets, SLAs    │
└───────────────────┘   └────────────────────┘
   하나의 서비스             또 다른 서비스
```

## 경계를 찾는 방법

- 명사나 DB 테이블이 아니라 **비즈니스 기능에 맞춤**(주문, 청구, 배송).
- 경계 내부는 **높은 응집도**, 경계를 넘어서는 **느슨한 결합**.
- **유비쿼터스 언어(ubiquitous language)**가 바뀌는 지점을 주시 — 보통 그곳이 컨텍스트 경계.
- **context map(컨텍스트 맵)**을 사용해 관계(상류/하류)를 문서화.

## 안티패턴

```text
✗ 엔티티 서비스("User service", "Product service") — 너무 세밀, 수다스러움
✗ 기술 계층으로 분할("database service")
✗ 모든 작업마다 분산 트랜잭션을 강요하는 경계
```

두 서비스가 하나의 작업을 완료하기 위해 끊임없이 서로를 호출한다면, 경계가 잘못되었을 가능성이 큽니다.

## 왜 중요한가

초기에 결정된 경계는 나중에 옮기기가 매우 비쌉니다. 다른 팀이 의존하는 API와 데이터베이스로 굳어지기 때문입니다.

DDD bounded context는 비즈니스를 따라 그 선을 긋는 원칙적인 방법을 제공하므로, 서비스가 응집력을 유지하고 끊임없이 조율하는 대신 독립적으로 진화할 수 있습니다.