[DDD] 바운디드 컨텍스트(bounded context)

IT/기초 지식

개발자 두더지 2023. 5. 18. 22:32

728x90

※ 일본의 한 블로그 글을 번역한 포스트입니다. 오역 및 의역, 직역이 있을 수 있으며 틀린 내용은 지적해주시면 감사하겠습니다.

바운디드 컨텍스트란?

공식 DDD Reference의 정의는 다음과 같다.

바운디드 컨텍스트(Bounded Context)

특정 모델의 정의, 적용하는 경계를 명시적으로 나타내는 것. 대표적인 예는 서브 시스템이나 팀등이 있다.

바운디드 컨텍스트는 두 가지 시점에서 해설이 필요하다.

DDD에서는 모든 사람 (소프트웨어 개발자, 도메인 전문가)가 동일한 의미로 말을 사용하는 것을 목적으로 한다. 예를 들어, EC 사이트 상품을 판매하는 시스템을 생각해보자.

여기에서는 엔지니어와 판매 관리자 사이에, "상품"에 관해서 동일한 모델을 공유한다. 엔지니어와 판매부의 커뮤니케이션이 원활하여, "상품"에 대해서 동일한 모델, 언어를 공유할 수 있다.

그럼 판매에서 배송까지의 시스템 관리를 하고 싶다고 해보자. 배송하는 사람 입장에서는 "상품"이라고 했을 때에 완전히 다른 것을 떠올리게 된다.

DDD에서는 모든 사람이 동일한 의미로 말을 사용하는 것을 목적으로 한다고 했었기에, 강제적으로 "상품"의 개념을 통일해보자.

까다로워지기 시작했다. 게다가 도메인 구동 설계에서는 이것을 코드로 구현하는 것을 목표로 하기 때문에 "상품"의 동작을 "상품" 클래스에 채워가는 형태가 된다.

더욱이, 요구 관리까지를 시스템화하게 되어, 카운터 파트로 경리부 사람도 늘었다. 당연히 경리부도 "상품"에 관해 다른 이미지를 가지고 있다.

이 상태에서 모든 사람이 동일한 의미로 말을 사용하는 것을 목표로 한다는 것이 가능해질까? 보면 알 수 있듯, 시스템이 크면 클수록, 관계자 모두를 통일한 모델을 만드는 것은 어려워 진다.

과거에는 비즈니스 전체의 통일 모델을 구축하라는 조언이 있었지만, DDD에서는 "대규모 시스템 도메인 모델의 완전한 통합은 현실적으로 실현이 불가능하고 비용 대비 효과가 낮다"라고 말한다.

따라서 DDD에서는 커다란 시스템을 "바운디드 컨텍스트"로 나누고, 각각 모델, 언어를 통일하는 것을 목표로 한다.

컨텍스트를 분할해봤다! "판매 컨텍스트" "배송 컨텍스트" 각각 하나의 바운디드 컨텍스트가 됐다. 각각의 컨텍스트 내에서는 관계자 간에 "상품"은 반드시 동일한 모델, 용어로 통일하고 있다.

이정도 범위라면 모델, 용어를 통일하는 것이 현실적으로 가능하게 된다.

그럼 판매와 배송을 다른 컨텍스트로 정의하고, "상품"을 다른 모델로 했지만, 현실적으로 "상품"은 연결되어 있다. 그렇다는 것은 이 컨텍스트를 걸쳐 "상품"을 어떻게 다룰지 결정해야 한다는 것이다.

이러한 컨텍스트 간의 관계성을 간단한 그림으로 표시하는 것을 컨텍스트 맵핑이라고 말한다.

이와같이 이 순서로 DDD 설계의 첫 걸음을 뗀다.

1. 모델링 대상을 바운디드 컨텍스로 나눈다.

2. 컨텍스트간의 관계를 맵핑한다.

그 이유는 DDD에서는 "도메인 전문가와 소프트 웨어 전문가의 콜라보레이션으로 모델을 추구"하는 것을 목표로하지만, "모델"은 먼저 적용할 컨텍스트를 구분하지 않으면 정의할 수 없기 때문이다.

내용이 길어져서 바운디드 컨텍스트의 구현의 경우 다른 포스팅에서 다루고자한다. 관련 포스트 작성이 끝나면 이 포스트에 링크를 추가하도록 하겠다.

참고자료

728x90