개요

이 문서는 바운디드 컨텍스트를 나누는 방법을 정리한 것이다.

서론

바운디드 컨텍스트(Bounded Context) 는 특정 용어를 명확한 의미로 사용하는 명확히 정의된 경계이다. 즉, 도메인 모델이 적용되며 일관성을 유지하는 명시적인 경계다.

각 컨텍스트 내에서 용어는 고유한 의미를 가지므로, 바운디드 컨텍스트의 객체는 더 응집력 있고 명확하다.

바운디드 컨텍스트를 잘 나누면 개발 생산성이 향상되고 좋은 설계의 표준이 될 수 있다. 이 문서는 바운디드 컨텍스트를 효과적으로 나누는 방법을 설명한다.

도메인 주도 설계(DDD)에서는 바운디드 컨텍스트를 나누는 단일 절대 기준은 없다. 대신 여러 가지 요소를 함께 고려해야 한다.

유비쿼터스 언어는 가장 일반적인 구분 기준이다. 같은 용어가 다른 의미로 사용된다면, 이를 다른 컨텍스트로 분리해야 한다는 신호다.

예를 들어 “주문(Order)”이라는 용어가 마케팅, 배송, 회계 도메인에서 각각 다른 의미를 가진다면, 이는 서로 다른 컨텍스트로 취급해야 한다.

업무 프로세스 단위로 컨텍스트를 나눌 수 있다.
예를 들어, 주문 취소 프로세스는 주문 도메인에 속한다.

각 컨텍스트는 고유한 도메인 모델과 데이터 저장소를 가져야 한다. 다른 컨텍스트의 데이터를 직접 참조하지 않고 API 게이트웨이나 이벤트를 통해 참조해야 한다.

콘웨이 법칙(Conway’s Law) 에 따르면 팀 구조는 시스템 아키텍처에 영향을 준다. 팀 경계를 기준으로 컨텍스트를 나누면 높은 응집도와 낮은 결합도를 얻을 수 있다.

이벤트를 분석하면 컨텍스트 간의 의존 흐름을 파악할 수 있다. 이벤트에 의해 트리거된 작업이 다른 모델을 사용한다면, 컨텍스트를 분리해야 한다.

각 영역에 적용되는 규칙이 다르다면 해당 영역은 별도의 컨텍스트로 나누어야 한다.

바운디드 컨텍스트를 나누기 어려울 때는 컨텍스트 맵(Context Map) 을 도구로 활용할 수 있다.
컨텍스트 맵은 바운디드 컨텍스트 간의 의사소통, 통합 방식, 의존성 분리, 관계를 시각화한다.

컨텍스트 맵은 PlantUML + Context Map DSL, Structurizr, Draw.io / Lucidchart 등의 도구로 그릴 수 있다.

바운디드 컨텍스트는 DDD를 잘 구현하기 위한 핵심 개념이며, 이를 나누는 방법은 더욱 중요하다. 이번에 바운디드 컨텍스트를 나누는 방법과 컨텍스트 맵의 가치를 알게 되었다.

팀과 함께 컨텍스트 맵을 작성해야 한다면, 이 글이 좋은 참고 자료가 될 수 있다.