[개발 & 방법론 / DDD] 바운디드 컨텍스트 (BOUNDED CONTEXT)

진정한 DDD는 설계에 있다는 것을 여러가지 블로그들을 통하여 깨닫게 되었다. 

도메인 주도 개발 시작하기라는 책에서도 바운디드 컨텍스트가 언급된다. 

- http://www.yes24.com/Product/Goods/108431347

 

이제 부터 본격적으로 바운디드 컨텍스트(BOUNDED CONTEXT)에 대해 알아보자. 

 

BOUNDED-Context 란?

우리는 하나의 단어를 여러 의미로 사용하는 상황을 많이 마주했으며, 앞으로도 그런 식으로 계속 사용된다. 

모델은 특정 컨텍스트(문맥)에서 완전한 의미를 갖음. 같은 제품이라도 카탈로그 컨텍스트와 재고 컨텍스트는 의미가 서로 다르다. 

대표적인 예시를 들자면, Account로 표현 할 수 있다. 은행에서는 Account는 계좌이다. ERP 시스템에서 계정으로 사용된다.

 

즉, 같은 단어를 애플리케이션 전체 구조에서보면 다양한 도메인에서 반복되어 사용되는 것을 알 수 있다. 

용어가 중복되다보니, 개발자는 자기도 모르게 하나의 모델 즉, 도메인으로 처리하고 싶은 생각이들며 이러한 실수를 할 수 있다. 

하나의 모델이 다양한 도메인에서 사용되면, common 공통 코드에 넣고 싶은 유혹이 좔좔 흐른다. 

 

위에와 같은 오류를 막고자 BOUNDED CONTEXT는 존재한다. 

 

본격적으로 바운디드 컨텍스트 구조에 대해서 알아보자. 

 

바운디드 컨테스트는 도메인 모델만 포함되는 용어가 아니다. 

바운디드 컨텍스트는 도메인 기능을 사용자에게 제공하는 데 필요한 표현 영역, 응용 서비스, 인프라스트럭쳐 영역을 모두 포함한다. 

도메인 모델의 데이터 구조가 바뀌면 DB 테이블 스키마도 변경되므로 테이블도 바운디드 컨텍스트에 포함된다. 

 

즉, 바운디드 컨텍스트는 도메인 기능을 제공하는 데 필요한 모든 요소를 포함

 

유비쿼터스 언어는 바운디드 컨텍스트 안에서 의미를 갖고 존재한다. 

 

좋은 BOUNDED CONTEXT

 

하나의 BOUNDED CONTEXT는 하나의 팀에만 할당되어야 한다.

- 하나의 팀은 여러 개의 BOUNDED CONTEXT 할당 받을 수 있다. 

- 둘 이상의 팀이 하나의 BOUNDED CONTEXT를 같이 관리하는 건 안티 패턴

각각 BOUNDED CONTEXT는 각각의 개발 환경을 가질 수 있다. 

 

 

https://www.youtube.com/watch?v=n_9fBLl1gb4&t=701s

해당 유튜브 영상 댓글에 유비쿼터스언어와 바운디드 컨텐스트가 DDD에 끼치는 역할에 대한 이야기도 있다. 

 

 

컨텍스트 맵 

- 컨텍스트 맵은 바운디드 컨텍스트간의 관계를 표시한 것으로 시스템 전체 구조를 볼 수 있다. 

- 주요 애그리거트와 함께 표시해 모델 관계를 명확히 드러낼 수 있다.

- 하위 도메인과 일치하지 않는 바운디드 컨텍스트 조정과 집중해야할 핵심 도메인을 파악하는데 도움이 된다. 

 

 

DDD 와 OOP 차이는 무엇인가? 

- OOP는 상속이나 재활용성을 위한 공통된 데이터를 공유하는 것을 중시

- DDD는 도메인의 분리를 중시한다.