DDD의 Bounded Context 알아보기

DDD에서 유독 어렵다고 유명한 개념인 Bounded Context에 대해서 알아보겠습니다!

DDD 자체에 관한 글을 아래 2개 글을 참고해 주세요.

핵사고날? 클린 아키텍처? DDD?

DDD, 난해한 용어 없이 상식적으로 이해하기

---

간단한 예시

예를 들어 Order라는 용어를 봐 보겠습니다. 이 용어는 똑같이 Order라고 지칭해도 여러 앱에 따라 다른 의미를 가질 수 있습니다.

• 식당에서 쓰는 주문 시스템의 Order: 고객이 원하는 상품
• 커머스 사이트에서의 Order: 상품의 주문 (배송 상태, 결제 수단 등이 포함)
• 군사 시스템에서의 Order: 상위 계급의 명령

만약 군대 내에서 쓰는 시스템을 개발 중이라면 군인 식당에서 각종 식자재를 발주하고 식당에서 주문을 받고, 군인들끼리 명령을 전달하는 요소가 포함 돼 있을 수 있습니다. 이런 상황에서 Order를 공통으로 사용한다면 굉장히 헷갈릴 겁니다.

여기서 Order라는 용어가 각각의 분야에서 다른 의미를 갖는데, Order 뿐만 아니라 여러 도메인 용어들이 1가지 의미로 통용될 수 있는 논리적 경계를 Bounded Context라고 합니다.

---

Bounded Context를 나눴는데, 그래서 뭐 어떻게 할까?

Bounded Context를 나눴으면 일반적으로 이 경계를 엄격하게 분리하고, 다른 Bounded Context 끼리는 interface를 통해서 소통하는 식으로 구현합니다.

Bounded Context 끼리는 서로 다른 용어를 쓰고, 다른 비즈니스 요구사항이 있는 경우가 많습니다. 그래서 세부 구현도 다르고, 인프라 구성도 다르기 때문에 일반적으로는 분리하는 게 바람직하다고 여겨집니다. (MSA에서는 다른 MS로 만들고, Multi-Module을 지원한다면 다른 Module로 만들고)

하지만 Bounded Context는 어디까지나 논리적인 개념이기 때문에 서로 다른 Bounded Context로 구분 했어도 시간이 지나면서 유사해지거나, 아니면 애초에 비슷할 수도 있습니다. 이 경우에는 실용적으로 생각해서 엄격하게 분리하지 않는 게 좋을 수도 있습니다.

---