도메인주도개발 시작하기 9장 바운디드컨텍스트

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

- 인프라 영역에서 외부 시스템과의 연동을 처리

- RecSystemClient에서 도메인 모델 변환하는 작업을 처리

- 두 모델 간 변환 과정이 복잡하면 변환 처리를 위한 별도 클래스 생성 가능

- Rest API를 통해 두 바운디드 컨텍스트를 직접 통합할 수 있고, 메시지큐를 사용하여 간접적으로 통합할 수도 있음

- 비동기적으로 처리 가능

- 단, 두 바운디드 컨텍스트가 사용할 메시지의 데이터 구조를 맞춰야

- 변경 내용을 여러 컨텍스트에 pub-sub 가능

그럼 여기서 , microservice간 restapi 와 message queue로 처리하는 방식의 차이는 뭘까

 

REST API 통신:

장점:

- 간단하고 직관적인 통신 방식으로, HTTP 프로토콜을 사용하여 통신하기 때문에 구현이 비교적 쉽다.

- 대부분의 개발자가 익숙하며, 다양한 플랫폼과 언어에서 지원

- 요청과 응답이 직접적으로 이루어지기 때문에 디버깅이 용이함

단점:

- 동기적인 통신 방식이기 때문에 서비스 간 결합도가 높아질 수 있다

- 서비스가 서로 의존하는 경우 서비스 간의 결합이 높아져 유연성이 감소할 수 있다.

- 서비스가 비동기적으로 통신하는 것을 지원하지 않으므로, 높은 병렬성을 달성하기 어렵다.

 

Message Queue를 이용한 통신:

장점:

- 비동기적인 통신을 지원하여 서비스 간의 결합도를 낮출 수 있다, 각각의 서비스는 메세지를 보내고

받는데만 관심을 갖는다.

- 서비스 간의 의존성이 낮아져 확장성과 유연성이 향상

- 메세지 큐 안에서 메세지를 안전하게 보관하고 로그처리가 되므로, 수신 서비스가 다운되더라도 메세지의

유실이 되지않고 , 에러를 추적하기 쉽다.

단점:

- 구현 및 관리가 복잡

- 메세지 브로커의 추가적인 인프라 비용발생

 

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

- 호출자 : 상류, 피호출자 : 하류 관계로 의존

 

- 하류 컨포넌트는 상류 컨포넌트의 데이터와 기능에 의존

- Pub/sub 관계 있는 두 팀은 상호 협력이 필수, 상류는 함부로 API를 변경할 수 없음

- 하류 팀이 다수 존재하면 어려 하류 팀의 요구사항을 수용할 수 있는 API를 만들고 이를 서비스 형태로 공개

 

- 하류 컴포넌트는 상류 서비스 모델이 자신의 도메인 모델에 영향을 주지 않도록 보호해주는 완층 지대를 만들어야

# 컨텍스트 맵

- 전체 비즈니스를 조망할 수 있는 지도

- 하위 도메인이나 조직조를 함께 표시하면 도메인을 포함한 전체 관계를 이해하는 도움이 된다.