CHAPTER 9. 도메인 모델과 BOUNDED CONTECT

1. 도메인 모델과 경계

• 모델은 특정한 컨텍스트 하에서 완전한 의미를 갖는다
• 같은 제품이라도 카탈로그 컨텍스트와 제고 컨텍스트에서 의미가 서로 다르다.
• 이렇게 구분되는 경계를 갖는 컨텍스트를 DDD에서는 BOUNDED CONTEXT라고 부른다.

2. BOUNDED CONTECT

• BOUNDED CONTEXT는 모델의 경계를 결정하며 한 개의 BOUNDED CONTEXT는 논리적으로 한 개의 모델을 갖는다.
• BOUNDED CONTEXT는 용어를 기준으로 구분한다.
• 여러 하위 도메인을 하나의 BOUNDED CONTEXT에서 개발할 때 주의할 점은 하위 도메인의 모델이 뒤섞이지 않도록 하는 것이다.
• 한개의 BOUNDED CONTEXT에서 여러 하위 도메인을 포함하더라도 하위 도메인마다 구분되는 패키지를 갖도록 구현해야 한다.
  

3. BOUNDED CONTECT의 구현

• BOUNDED CONTEXT는 도메인 모델 뿐만 아니라 도메인 기능을 사용자에게 제공하는데 필요한 표현 영역, 응용 서비스, 인프라 영역 등을 모두 포함한다.
• 모든 BOUNDED CONTEXT를 반드시 도메인 주도로 개발할 필요는 없다. 복잡한 도메인 로직을 갖지 않는 CONTEXT는 단순한 CRUD방식으로 구현해도 큰 문제가 없다.

4. BOUNDED CONTECT간 통합

• 각각의 BOUNDED CONTEXT를 사용하는 2개의 팀이 서로 관련된 BOUNDED CONTEXT를 개발하면 두 BOUNDED CONTEXT간 통합이 필요해진다.

rest api 호출 방식

MQ 처리 방식

5. BOUNDED CONTECT간 관계

• BOUNDED CONTEXT 다양한 방식으로 관계를 맺는다. 가장 흔한 관계는 한쪽에서 API를 제공하고 다른 한쪽에서 그 API를 호출하는 관계이다.
• REST API가 대표적이며, 이 관계에서 API를 사용하는 BOUNDED CONTEXT는 API를 제공하는 BOUNDED CONTEXT에 의존하게 된다.

• API를 제공받는 팀이 다수 존재하면, 제공해 주는 팀은 여러 팀들의 요구사항을 수용할 수 있는 API를 만들고 시를 서비스 형태로 공개해서 서비스의 일관성을 유지할 수 있다. 이런 서비스를 가리켜 공개 호스트 서비스(OPEN HOST SERVICE)라고 한다.

• 두 BOUNDED CONTEXT가 같은 모델을 공유하는 경우도 있다.
• 주문을 표현하는 모델을 공유함으로써 중복된 개발을 막을 수 있다. 두 팀이 공유하는 모델을 공유 커널(SHARD KERNEL)이라고 부른다.