: 바운디드 컨텍스트는 모델의 경계를 결정한다.
: 한 개의 바운디드 컨텍스트는 논리적으로 한 개의 모델을 갖는다.
: 바운디드 컨텍스트는 용어를 기준으로 구분된다. 카탈로그 컨텍스트와 재고 컨텍스트는 서로 다른 용어를 사용하므로 이 용어를 기준으로 컨텍스트를 분리할 수 있다.
: 바운디드 컨텍스트는 실제로 사용자에게 기능을 제공하는 물리적 시스템으로 도메인 모델은 이 바운디드 컨텍스트 안에서 도메인을 구현한다.
: 이상적으로 하위 도메인과 바운디드 컨텍스트가 일대일 관계를 가지면 좋겠지만 현실은 그렇지 않을 때가 많다.
: 바운디드 컨텍스트는 기업의 팀 조직 구조에 따라 결정되기도 하는데 예를 들어 주문 하위 도메인이라도 주문을 처리하는 팀과 복잡한 결제 금액 계산 로직을 구현하는 팀이 따로 있다고 해보자.
: 이 경우 주문 하위 도메인에 주문 바운디드 컨텍스트와 결제 금액 계산 바운디드 컨텍스트가 존재하게 된다.
: 용어를 명확하게 구분하지 못해 두 하위 도메인을 하나의 바운디드 컨텍스트에서 구현하기도 한다.
: 예를 들어 카탈로그와 재고 관리가 아직 명확하게 구분되지 않은 경우, 두 하위 도메인을 하나의 바운디드 컨텍스트에서 구현하기도 한다.
: 규모가 작은 기업은 전체 시스템을 한 개 팀에서 구현할 때도 있다.
: 예를 들어 소규모 쇼핑몰은 한 개의 웹 애플리케이션으로 온라인 쇼핑을 서비스하며 하나의 시스템에서 회원, 카탈로그, 재고, 구매, 결제와 관련된 모든 기능을 제공한다.
⇒ 즉 여러 하위 도메인을 한 개의 바운디드 컨텍스트에서 구현한다.
: 여러 하위 도메인을 하나의 바운디드 컨텍스트에서 개발할 때 주의할 점은 하위 도메인의 모델이 섞이지 않도록 하는 것이다.
: 한 프로젝트에 각 하위 도메인의 모델이 위치하면 아무래도 전체 하위 도메인을 위한 단일 모델을 만들고 싶은 유혹에 빠질 수 있다.
: 이런 유혹에 걸려들면 결과적으로 도메인 모델이 개별 하위 도메인의 특성을 제대로 반영하지 못해서 하위 도메인별로 기능을 확장하기 어려워지고 이는 서비스 경쟁력을 떨어트리는 원인이 된다.
: 비록 한 개의 바운디드 컨텍스트가 여러 하위 도메인을 포함하더라도 하위 도메인마다 구분되는 패키지를 갖도록 구분하여 구현해야하며 이렇게 함으로써 하위 도메인을 위한 모델이 서로 뒤섞이지 않고 하위 도메인마다 바운디드 컨텍스트를 갖는 효과를 낼 수 있다.
