DDD(Domain-Driven Design)에 나오는 개념.
DDD deals with large models by dividing them into different Bounded Contexts and being explicit about their interrelationships.
― Martin Fowler
도메인이 거대하면 하나의 단어도 회사의 부서에 따라 미묘하게 다른 의미를 지닐 수 있고 이게 모델링할 때 애매한 지점들을 많이 만든다.
같은 개념이라도 컨텍스트가 다르면 모델링이 다를 수 있기 때문이다.
예를 들어,
학생
- 대학교 교육에서의 학생: 강의 수강, 성적의 주체
- 대학교 도서관에서의 학생: 도서 대출, 연체료 납부의 주체
상품 (이커머스)
- 주문 처리에서의 상품: 가격이 매겨지고 배송되는 고객 주문의 대상
- 인벤토리 관리에서의 상품: 공급자에게서 받아 물류 창고에 보관되는 재고 관리의 대상
개발이란 게 그렇듯, 크거나 복잡해서 문제가 생기면 나누기를 시전.
큰 도메인을 단어의 의미가 통일되는 (비지니스) 영역들로 나눌 때,
이렇게 나누어진 영역들이 바로 Bounded Contexts이고,
비로소 컨텍스트 안에서 단어를 용어라고 부를 수 있게 된다.
경험담
실제로 회사에서 보았던 일이다.
기존 광고 사업 운영 시스템이 광고 계약 하나에 광고 영상을 하나밖에 등록하지 못하게 되어 있었는데,
실제 운영에서는 광고 영상을 여러 개 등록해야 했고,
결국 동일한 계약을 여러 개의 계약으로 등록하는 변칙이 널리 사용되었다. ( 데이터는 혼돈 속으로.. )
이런 일이 벌어진 것은, '광고 계약'과 '광고 영상 송출'이 엄연히 다른 컨텍스트인데도 하나의 컨텍스트로 강하게 엮여 있었기 때문이다. ( 심지어 회사 내 담당 부서도 다름 )
애그리거트(Aggregate)와의 관계
하나 이상의 애그리거트가 바운디드 컨텍스트에 속할 수 있다.
예)
거래(매매) // Bounded Context
- { 주문(root), 주문상품 } // Aggregate
- { 상품(root), 상품쿠폰 } // Aggregate
