9장 도메인 모델과 바운디드 컨텍스트

9.1 도메인 모델과 경계

• 모델은 특정한 컨텍스트(문맥)하에서 완전한 의미를 갖는다. 같은 제품이라도 카탈로그 컨텍스트와 재고 컨텍스트에서 의미가 서로 다르다.
• DDD에서는 구분되는 경계를 갖는 컨텍스트를 바운디드 컨텍스트라고 부른다.

9.2 바운디드 컨텍스트

• 여러 하위 도메인을 하나의 바운디드 컨텍스트에서 개발할 때 주의할 점은 하위 도메인의 모델이 섞이지 않도록 하는 것이다.
• 비록 한 개의 바운디드 컨텍스트가 여러 하위 도메인을 포함하더라도 하위 도메인마다 구분되는 패키지를 갖도록 구현해야 한다.

9.3 바운디드 컨텍스트 구현

• 모든 바운디드 컨텍스트를 반드시 도메인 주도로 개발할 필요는 없다.
  • 각 바운디드 컨텍스트는 도메인에 알맞은 아키텍처를 사용한다.
• 한 바운디드 컨텍스트에서 두 방식을 혼합해서 사용할 수도 있다.
  • CQRS 패턴은 Command Query Responsibility Segregation의 약자로 상태를 변경하는 명령 기능과 내용을 조회하는 쿼리 기능을 위한 모델을 구분하는 패턴인다.

9.4 바운디드 컨텍스트 간 통합

• 두 바운디드 컨텍스트간 통합하는 방법
  • REST API 호출
  • 메시지 큐 - 비동기

9.5 바운디드 컨텍스트 간 관계

고객 공급자 관계

• 상류 팀의 고객인 하류 팀이 다수 존재하면 상류 팀은 여러 하류 팀의 요구사항을 수용할 수 있는 API를 만들고 이를 서비스 형태로 공개해서 서비스의 일관성을 유지할 수 있다. → 공개 호스트 서비스라고 한다.
• 상류 컴포넌트의 서비스는 상류 바운디드 컨텍스트의 도메인 모델을 따른다.
• 따라서 하류 컴포넌트는 상류 서비스의 모델이 자신의 도메인 모델에 영향을 주지 않도록 보호해 주는 완충 지대를 만들어야 한다.
  • 외부 시스템과의 연동을 처리하는데 외부 시스템의 도메인 모델이 내 도메인 모델을 침범하지 않도록 막아주는 역할을 한다. → 안티 코럽션 계층이 됨
  • 두 바운디드 컨텍스트 간의 모델 변환을 처리해 주기 때문에 다른 바운디드 컨텍스트의 모델에 영향을 받지 않고 내 도메인 모델을 유지할 수 있다.

두 바운디드 컨텍스트가 같은 모델을 공유하는 경우

• 고유 커널을 통해 중복을 줄여 줄 수 있다.
• 여러 팀이 한 모델을 공유하기 때문에 한 팀에서 임의로 모델을 변경하면 안되며 함께 밀접한 관계를 유지해야 한다.

독립 방식

• 두 바운디드 컨텍스트 간에 통합하지 않으므로 서로 독립적으로 모델을 발전시킨다.
• 즉, 두 바운디드 컨텍스트 간의 통합은 수동으로 이루어진다.
• 수동으로 통합하는 방식이 나쁜 것은 아니지만 규모가 커질수록 수동 통합에는 한계가 있으므로 규모가 커지기 시작하면 두 바운디드 컨텍스트를 통합해야 한다.

9.6 컨텍스트 맵

• 바운디드 컨테스트 간의 관계를 표시한 것
• 시스템의 전체 구조를 보여준다.
• 하위 도메인과 일치하지 않는 바운디드 컨텍스트를 찾아 도메인에 맞게 바운디드 컨텍스트를 조절하고 사업의 핵심 도메인을 위해 조직 역량을 어떤 바운디든 컨텍스트에 집중할지 파악하는데 도움을 준다.