Bounded Context의 정의
도메인 주도 설계(DDD)에서 Bounded Context(경계 컨텍스트)는 특정 도메인 모델이 유효하게 적용되는 범위를 뜻합니다. 하나의 시스템 안에는 여러 도메인 개념이 존재하는데, 같은 용어라도 부서나 업무 맥락에 따라 의미가 달라질 수 있습니다. Bounded Context는 이런 모호함을 없애기 위해 ‘이 용어는 이 범위 안에서만 이런 의미를 가진다’라고 명확히 선을 긋는 역할을 합니다.
같은 단어, 다른 의미: 경계가 필요한 이유
예를 들어 쇼핑몰 시스템에서 ‘상품’이라는 단어를 생각해봅시다. 영업팀 입장에서 상품은 ‘가격, 할인율, 프로모션 정보’를 포함하는 개념이지만, 물류팀 입장에서 상품은 ‘무게, 부피, 재고 위치’ 같은 정보가 중요합니다. 하나의 ‘상품’ 클래스에 이 모든 속성을 다 넣으면 클래스는 비대해지고, 팀 간 요구사항이 부딪힐 때마다 코드를 수정해야 합니다.
Bounded Context는 이 문제를 ‘영업 컨텍스트의 상품’과 ‘물류 컨텍스트의 상품’을 분리함으로써 해결합니다. 마치 회사에서 같은 ‘김대리’라는 사람이 영업팀에서는 ‘고객 담당자’로, 인사팀에서는 ‘평가 대상 직원’으로 다르게 취급되는 것과 비슷합니다. 각 팀은 자신의 컨텍스트 안에서만 유효한 모델을 갖고, 다른 컨텍스트와는 명시적인 인터페이스(Context Map)를 통해 소통합니다.
코드 레벨에서 보면 같은 이름이라도 각 컨텍스트마다 별도의 클래스나 모듈로 구현됩니다.
- 영업 컨텍스트:
class Product { price; discountRate; promotion; } - 물류 컨텍스트:
class Product { weight; volume; warehouseLocation; }
실무에서 Bounded Context를 쓰는 이유
실무에서 Bounded Context는 주로 마이크로서비스 아키텍처의 서비스 분리 기준으로 활용됩니다. 하나의 거대한 시스템을 무작정 기능 단위로 쪼개면 서비스 간 결합도가 높아지고 유지보수가 어려워지지만, Bounded Context를 기준으로 나누면 각 서비스가 독립적인 도메인 모델과 데이터베이스를 가질 수 있어 변경에 유연하게 대응할 수 있습니다.
또한 팀 구조와도 밀접하게 연결됩니다. 각 Bounded Context를 하나의 팀이 전담하면 팀 간 커뮤니케이션 비용이 줄고, 도메인 전문성을 살려 빠르게 의사결정을 내릴 수 있습니다. 결국 Bounded Context는 단순한 설계 기법을 넘어, 조직 구조와 시스템 아키텍처를 일치시키는 실용적인 도구라고 할 수 있습니다.