Chapter 3: 서브도메인과 전략적 설계

💡 책에서 기억하고 싶은 내용

서브도메인은 무엇인가?

• 서브도메인 은 전체 비즈니스 도메인의 하위 부분이다

  • 하나의 논리적 도메인 모델을 나타낸다

• 비즈니스 도메인은 보통 전체를 포괄적으로 생각하기엔 너무 크고 복잡하다

  • 거대하고 복잡한 프로젝트에서 문제 영역을 이해할 수 있도록, 전체 비즈니스 도메인을 논리적으로 쪼개는 데 서브도메인을 사용할 수 있다

• 서브도메인에는 크든, 작든 비즈니스에 대한 전략적 의의가 있다

• 서브도메인을 개발하는 데 DDD를 사용했다면 명확한 바운디드 컨텍스트 를 구현할 수 있따

서브도메인의 유형

프로젝트에는 세 가지 주요 서브도메인 유형이 있다

• 핵심 도메인

  • 보편언어 를 신중하게 만들기 위한 전략적 투자 영역

  • 주요 자원을 할당하는 명시적인 바운디드 컨텍스트 이며, 잘 정의된 도메인 모델 이 존재한다

  • 다른 경쟁자들에 대한 차별화를 만들 영역 이기 때문에 높은 우선순위를 갖는다

    • 기업이 뛰어나야 하는 부분 에 대한 경계를 구분해준다

    • 소프트웨어에서 가장 큰 투자가 필요한 곳이다

• 지원 서브도메인

  • 이미 존재하는 제품으로 해결할 수 없는 맞춤 제작 개발이 필요한 모델링 영역 을 의미한다

• 일반 서브도메인

  • 기존 제품 구매를 통해 바로 충족시킬 수 있는 경우에 해당한다

복잡성 다루기

• 비즈니스 도메인 안의 시스템 경계 중 일부는 레거시 시스템일 가능성이 높다

  • 이 경우 문제 영역 에 대해 논의하기 위한 도구로 서브도메인 을 사용해야 한다

• 실제 상황에서의 일부 레거시 시스템들은 바운디드 컨텍스를 기반으로 설계하는 DDD의 방향과 상충되기 때문에 이것들을 unbounded 레거시 시스템 으로 여길 수밖에 없다

  • 이런 레거시 시스템은 앞에서 큰 진흙 덩어리 로 언급했던 것이기 때문이다

  • 레거시 시스템을 논할 때 그 안에 몇 개 혹은 더 많은 논리적 도메인 모델 이 존재한다면, 이것을 서브도메인 으로 생각해볼 수 있다

• 서브도메인을 활용하면, 작업 중이거나 관련 있는 핵심 도메인을 하나의 간단한 다이어그램 안에 표현해볼 수 있다

  • 이 다이어그램은 서브도메인 간 의존성을 이해하는 데 도움을 줄 것이다

• DDD를 사용할 때, 바운디드 컨텍스트와 서브도메인은 1:1 관계 를 맺어야 한다

  • 1개의 바운디드 컨텍스트 안에 오직 1개의 서브도메인 모델을 두는 것을 목표로 한다

  • 이는 바운디드 컨텍스트를 정확하게 유지 시키고, 핵심 전략 목표에 집중 하는데 도움을 준다

• 만약 핵심 도메인 안에 존재하는 동일한 바운디드 컨텍스트 안에 다른 모델 을 만들어야 하는 상황이라면, 핵심 도메인으로 부터 완전히 분리된 형태 로 그 모델을 별도의 영역에 정의해야 한다

  • 이것은 하나의 모델이 핵심을 이루고, 다른 모델들은 지원하는 역할이라는 구성을 명확하게 나타낸다

  • 이처럼 서브도메인을 구분하는 일은 해결 영역에 계속 적용하게 될 것이다

Chapter 3 요약

• 서브도메인은 무엇이고, 문제 영역과 해결 영역에서 어떻게 사용하는가?

  • 서브도메인은 전체 비즈니스 도메인의 하위 부분이다

• 핵심 도메인과 지원 서브도메인, 일반 서브도메인의 차이

  • 핵심 도메인 - 보편언어를 신중하게 만들기 위한 전략적 투자 영역

  • 지원 서브도메인 - 맞춤 제작 개발 필요

  • 일반 서브도메인 - 기존 제품 구매로 충족 가능

• 큰 진흙 덩어리 레거시 시스템과의 통합을 고려할 때, 서브도메인을 사용할 수 있는 방법

• DDD의 바운디드 컨텍스트와 서브도메인을 일대일 관계로 맺는 것의 중요성

• 핵심 도메인과 지원 도메인을 2개의 서로 다른 바운디드 컨텍스트로 분리하는 것이 현실적이지 않을 때, DDD 모듈로 분리하는 방법

  • 핵심 도메인으로 부터 분리된 모듈 (Java의 package) 형태로 별도 영역에 정의한다