Bounded Context와 개발팀

...

바운디드 컨텍스트는 의미적으로 동일한 컨텍스트의 범위를 표현한다. 이것은 그 범주 내에서 소프트웨어 모델의 각 컴포넌트는 특정한 의미를 갖고, 특정한 일을 수행한다는 의미다. 바운디드 컨텍스트 내에 존재하는 컴포넌트들은 컨텍스트에 특화돼 있으며, 컨텍스트 안에서 의미가 살아난다. (이 말은 곧, 해당 BC를 벗어나는 그 컴포넌트는 의미가 없다는 뜻, UL이 다르기 때문, 예를들어 주문BC의 주문과 배송BC의 주문은 다른 의미일 수 있음, 또 다른 예 처방에서의 Order와 원무에서의 Order는 다를 수 있음)

바운디드 컨텍스트는 모델이 구현되는 곳이고, 바운디드 컨텍스트마다 각각 분리된 소프트웨어 산출물이 나온다.
(즉 BC마다 물리적으로 독립된 시스템이란 의미)

- Domain-Driven Design Distilled, 반 버논 p38

...

바운디드 컨텍스트, 팀 그리고 소스 코드 리파지토리

각각의 바운디드 컨텍스트는 단일 팀에만 할당돼야 하고, 각 바운디드 컨텍스트마다 독립적인 소스 코드 리파지토리가 있어야 한다. 한 팀은 다수의 바운디드 컨텍스트에 대해 일을 할 수 있지만, 다수의 팀이 하나의 바운디드 컨텍스트를 수행할 수는 없다. 보편언어를 나눈 것과 같은 방법으로 바운디드 컨텍스트마다 소스 코드와 데이터베이스 스키마도 명확히 분리 (이말은 서비스별 DB 독립을 의미한다, DB를 공유한다는 것은 UL과 모델을 공유한다는 의미이므로 모델의 모호, 통합, 큰 진흙 덩어리가 될 수 있다)한다. 메인 소스 코드와 함께 테스트와 단위 테스트를 유지해야 한다.

하나의 바운디드 컨텍스트를 한 팀이 수행한다는 것은 특히 중요한데, 이는 다른 팀이 소스 코드를 변경할 때 반갑지 않은 문제가 발생할 가능성을 완전히 제거할 수 있기 때문이다. 각 팀은 각자의 소스 코드와 데이터베이스를 소유하고, 공식 인터페이스를 정의해서 바운디드 컨텍스트를 다른 팀이 사용할 수 있게 허용한다. 이것이 DDD 사용의 이점이다.

- Domain-Driven Design Distilled, 반 버논 p41

...

위의 내용을 요약하면 다음과 같다

 

BC : 개발팀 = 1 : 1 (가급적 하나의 BC를 한팀이)

BC : 개발팀 = N : 1 (O 하나의 개발팀이 여러 BC(시스템)를 관리할 수 있지만)

BC : 개발팀 = 1 : N (X  하나의 BC(시스템)를 여러 개발팀이 담당할 수 없다)