0. 알아보게 된 이유
이전 글에서 DDD에서 중료한 개념 중 하나인 Ubiquitous Language에 대해 정리했다.
유티쿼터스 언어를 통해 이해관계자들이 같은 의미의 용어를 사용하도록 맞출 수 있지만, 실제로 시스템이 커질수록 하나의 언어만으로 모든 영역을 설명하는 것이 어려워진다.
업무 영역이 커지면 같은 단어라도 서로 다른 의미로 사용되는 경우가 생기고, 이로 인해 설계가 점점 복잡해지는 문제가 발생한다.
이 문제를 해결하기 위해 DDD에서는 도메인을 하나로 보지 않고 여러개의 경계로 나누는 개념을 제시하는데, 이 개념이 바로 Bounded Context이다.
이번 글에서는
Bounded Context란 무엇인지- 왜 필요한지
- 실제 설계에서 어떻게 나누는지
를 중심으로 정리해보려고 한다.
1. Bounded Context란 무엇인가?
Bounded Context는 특정한 의미를 가지는 모델이 적용되는 범위를 말한다.
DDD에서는 하나의 시스템 안에서도 여러개의 도메인이 존재할 수 있고, 각 도메인은 서로 다른 규칙과 의미를 가진다.
이때 하나의 모델이 적용되는 경계를 명확하게 나누는 것이 Bounded Context이다.
즉,
1
모델이 유효하게 사용되는 범위를 명확하게 나눈 경계
라고 볼 수 있다.
2. 왜 필요한가?
단순한 시스템에서는 하나의 모델로도 충분하다. 하지만 서비스가 커질수록 다음과 같은 문제가 발생한다.
- 같은 단어를 서로 다른 의미로 사용한다
- 기능이 많아질수록 코드가 복잡해진다
- 하나의 변경이 전체 시스템에 영향을 준다
- 도메인 규칙이 서로 충돌한다
이러한 문제는 설계가 잘못된 것이 아니라 도메인의 경계를 나누지 않았기 때문에 발생하는 경우가 많다.
DDD에서는 이 문제를 해결하기 위해
- 도메인을 나누고
- 각 도메인마다 모델을 따로 두고
- 경계를 명확하게 정의하라고 말한다.
이 경계가 바로 Bounded Context이다.
3. 하나의 용어가 다른 의미를 가지는 경우
쇼핑몰 시스템을 예로 들어보자. 주문 시스템과 배송 시스템이 있다고 가정한다.
- 주문 도메인에서의
Order- 결제가 완료된 주문
- 취소 가능 상태
- 상품 정보 포함
- 배송 도메인에서의
Order- 배송 요청 정보
- 주소 정보 포함
- 배송 상태 관리
같은 Order라는 단어를 사용하지만 의미가 완전히 다르다.
이 상태에서 하나의 모델로 만들면
- 필드가 계속 늘어나고
- 조건이 계속 늘어나고
- 코드가 복잡해진다
그래서 도메인을 경계 별로 나누어 구분한다.
| Context | 의미 |
|---|---|
| Order Context | 주문 관리 |
| Delivery Context | 배송 관리 |
| Payment Context | 결제 관리 |
각 Context안에서만 모델이 유효하다. 이것이 Bounded Context이다.
4. 예시 - 병원 시스템
병원 시스템을 만든다고 가정해보자. 접수 / 진료 / 수납 / 처방 모두 다른 규칙을 가진다.
- 접수 도메인
- 환자 등록
- 예약확인
- 방문 처리
- 진료 도메인
- 진단
- 처방
- 진료 기록
- 수납 도메인
- 결제
- 보험처리
- 영수증
여기서 Patient라는 단어가 있다고 가정하자.
- 접수에서의 Patient
- 방문 여부
- 예약 정보
- 진료에서의 Patient
- 진료 기록
- 처방 기록
- 수납에서의 Patient
- 결제 정보
- 보험 정보
같은 단어지만 의미가 다르다. 그래서 Context를 나눈다.
| Context | 역할 |
|---|---|
| Reception Context | 접수 |
| Medical Context | 진료 |
| Billing Context | 수납 |
각 Context안에서만 모델을 사용한다.
5. Bounded Context의 특징
Bounded Context는 다음 특징을 가진다.
- 하나의 모델은 하나의 Context 안에서만 사용된다.
Context마다 유비쿼터스 언어가 다를 수 있다.Context사이에는 명확한 경계가 있다.Context는 독립적으로 변경 가능해야 한다.Context는 서로 직접 의존하지 않는 것이 좋다.
DDD에서는
1
큰 시스템을 잘 나누는 것이 좋은 설계의 시작이다.
라고 본다.
6. 정리
Bounded Context란
하나의 모델이 유효하게 사용되는 범위를 나누는 경계이며, 복잡한 시스템을 여러개의 의미있는 영역으로 분리하기 위한 개념이다.
시스템이 커질수록 하나의 모델로 모든 것을 표현하려고 하면
- 코드가 복잡해지고
- 변경이 어려워지고
- 이해하기가 힘들어진다
DDD는 이를 해결하기 위해
- 도메인을 나누고
Context를 나누고- 각
Context마다 모델을 따로 만든다.
이 과정을 통해 복잡한 시스템에서도 유지보수가 가능한 구조를 만들 수 있다.
7. 다음에 알아볼 내용
Bounded Context를 나누었다면 그 안에서 모델을 어떻게 구성할 것인지가 다음 문제이다.
DDD에서는 Context 내부의 모델을 구성할 때
EntityValue ObjectAggregateDomain Service
와 같은 개념을 사용한다.
다음 글에서는 Entity와 Value Object의 차이와 언제 어떤 기준으로 나누는지 정리해보려고 한다.