전략적 설계 - BOUNDED CONTEXT

바운디드 컨텍스트

• 하위 도메인마다 같은 용어라도 의미가 다르고 같은 대상이라도 지칭하는 용어가 다를 수 있기 때문에 한 개의 모델로 모든 하위 도메인을 표현하려는 시도는 올바른 방법이 아니며 표현할 수도 없다.

• 하위 도메인마다 사용하는 용어가 다르기 때문에 올바른 도메인 모델을 개발하려면 하위 도메인마다 모델을 만들어야 한다.

• 모델은 특정한 컨텍스트(문맥)하에서 완전한 의미를 갖는다.

• 이렇게 구분되는 경계를 갖는 컨텍스트를 DDD에서는 BOUNDED CONTEXT라고 부른다.

  • 분할과 정복은 비지니스를 해결해나가는 가장 중요한 방법이다!

  • 에릭 에반스의 "도메인 주도 설계" 의 부재가 "소프트웨어의 복잡성을 다루는 지혜" 이다.

  • 바운디드 컨텍스트는 어려운 개념이 아니다. 어떠한 문제를 해결하고 싶은지에 맞춰서 나누는 것이다.

좋은 바운디드 컨텍스트

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

  • 하나의 팀은 여러 개의 BOUNDED CONTEXT를 다룰 수 있다.

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

  • MSA 를 바운디드 컨텍스트 단위로 나누는 이유가 이것이다!

  • MSA 는 너무 어려운 작업이니, 간단하게 바운디드 컨텍스트 별로 패키지를 분리해보자!

컨텍스트 맵

• 컨텍스트 맵은 상호 교류하는 시스템의 목록을 제공하고, 팀 내 의사소통의 촉매 역할을 한다.

• 컨텍스트 맵을 통해서 거시적으로 시스템을 유추해 볼 수 있다.

예시1. 키친포스(제이슨 예시)

• 점선 : 하위도메인

• 실선 : 바운디드 컨텍스트

하위 도메인과 바운디드 컨텍스트를 구분하는 방법

• 하위 도메인

  • 비지니스 관점에서 도메인을 논리적으로 나눈 영역을 의미한다.

  • 자연스레 나누어진다.

• 바운디드 컨텍스트

  • 소프트웨어 설계 관점에서 도메인 모델이 적용되는 논리적인 영역을 의미한다.

  • 인위적으로 나뉘어진다. 내가 개발하기 편리한 방식으로 분류하는 것이다.

• 보통은 하위 도메인과 바운디드 컨텍스트가 1:1 로 매핑되는 경우는 많지 않다.

  • 위 예시에서도 매장 주문, 주문 테이블 도메인을 제외하고는 1:1 로 매핑되지 않는다.

  • 대체로 1:N 으로 매핑된다.

여러개의 컨텍스트가 하나의 하위 도메인에 포함되어 있다고 할 때, 각각의 컨텍스트가 하위 도메인을 바라보는 시각이 같을까?

• 다르다.

• 컨텍스트에 따라서 필요한 정보가 다를 수 있다.

• 예시

  • 상품 컨텍스트가 상품 도메인을 바라보는 입장 : 자신과 1:1 대응이 되는 도메인

  • 메뉴 컨텍스트가 상품 도메인을 바라보는 입장 : 메뉴를 등록하기 전 미리 등록되어 있어야 하는 도메인

비슷해 보이는 컨텍스트를 구분하는 방법 ( 상품 컨텍스트 -> 상품 컨텍스트, 메뉴 컨텍스트)

1. 물리적으로 다른 컨택스트로 구분해서 사용 (분리, 회피를 사용해도 서비스가 커짐에 따라 결국은 분리를 사용한다)

   1. ex, 상품 컨텍스트를 물리적으로 상품 컨텍스트, 메뉴 컨텍스트로 분리해서 사용한다.

   2. ex, 주문 컨텍스트를 물리적으로 매장 주문, 포장 주문, 배달 주문 컨텍스트로 분리해서 사용한다.

      1. 상태 변화의 라이프사이클이 다르기 때문에!

2. prefix(접두어) 를 사용해 한 컨텍스트 내에서 구분하는 방법 (회피)

   1. ex, 상품 컨텍스트 내에서 "상품_상품", "메뉴_상품" 의 형태로 구분한다.

예시2. NEXTSTEP 사이트

• U : upstream, 송신데이터

• D : downstream, 수신데이터

TIP!

• 데이터의 흐름이 단방향으로 갈 수 있도록 노력한다.

  • 데이터의 흐름이 양방향으로 간다는 말은, 결합도가 높다는 말이다.

  • 패키지 레벨에서 먼저 분리하고 시작한다면, 경계가 명확해지기 때문에, MSA 가 쉬워진다.

"예시2" 에서 사용한 바운디드 컨텍스트 구분 방법 (분리)

• 사용하고자 하는 기능에 따라서 바운디드 컨텍스트를 나누었다.

• 위 컨텍스트 맵은 하위 도메인과 바운디드 컨텍스트가 1:1로 매핑되는 것으로 보인다.

예시3. help.dex.org

"예시3" 에서 사용한 바운디드 컨텍스트 구분 방법 (분리)

• 사용하고자 하는 기능에 따라서 바운디드 컨텍스트를 나누었다.

• 위 컨텍스트 맵은 하위 도메인과 바운디드 컨텍스트가 1:1로 매핑되는 것으로 보인다.

• 상당히 직관적으로 내가 어떤 문제를 해결하고 싶냐에 따라서 바운디드 컨텍스트를 구분했다!

  • ex, 나는 결제와 관련된 문제를 해결하고 싶다면 PAYMENT & REFUNDS 페이지를 클릭할 것이다.

하위 도메인 (자연스레 나누어진다)

• 하위 도메인은 비즈니스 또는 요구사항에 따라서 구분할 수 있는 유스 케이스의 집합

핵심 하위 도메인

• 요구 사항이 자주 변경되고 복잡하여 집중적인 투자(인력, 마케팅 ..)가 필요한 하위 도메인 (서비스의 핵심 기능)

  • 돈이 되는 기능!

  • NEXTSTEP 의 핵심 하위 도메인은 미션!

• 하지만, 핵심 하위 도메인은 여러 외부요인에 따라서 변경된다.

  • ex. 비전의 변화, 상용 솔루션 등장 ..

지원 하위 도메인

• 핵심 하위 도메인을 뒷받침하는 하위 도메인

• 상대적으로 복잡도가 낮고, 외부요인에 따라서 핵심 하위 도메인이 될 수도 있다.

일반 하위 도메인

• 구현에 시간과 노력을 투자하는 것보다 기성 제품을 구매하거나 오픈 소스 솔루션을 채택하는 것이 비용 면에서 더 효율적이다.

  • ex. 결제는 토스 페이먼스 사용!

요구사항 vs 도메인 모델링

• 요구사항 : 클라이언트의 요구

• 도메인 모델링 : 요구사항을 정의하기 위한 아이디네이션

두 개념이 헷갈리는 이유

• 실무에서는 두 개념을 정의하는 주체가 다르다 .

  • 클라이언트

  • 개발자

• 하지만, 우리 미션에서는 내가 두 개념을 정의한다. 그래서 헷갈린다.