해결된 질문
작성
·
291
1
질문 드립니다!
질문1)
강의내용을 생각해보면
Bounded Context 단위도 하나의 서버가 될 수 있고
Aggregate 단위도 하나의 서버가 될 수 있는 것으로 보이는데
제가 이해한게 맞을까요?
질문2)
또한 Aggregate 와 마찬가지로 Bounded Context 도 다른 도메인으로의 요청은 Event 사용을 해야하는 걸까요?
질문3)
주문 Entity - 주문 아이템 Entity 관계가 Aggregate 로 연상됩니다... Bounded Context 개념이 적용된 코드가 Aggregate 쪽 코드와 다를까요?
답변 1
1
질문1)
강의내용을 생각해보면
Bounded Context 단위도 하나의 서버가 될 수 있고
Aggregate 단위도 하나의 서버가 될 수 있는 것으로 보이는데
제가 이해한게 맞을까요?
네 정확합니다.
질문2)
또한 Aggregate 와 마찬가지로 Bounded Context 도 다른 도메인으로의 요청은 Event 사용을 해야하는 걸까요?
아닙니다. 강의에선 비동기 방법에 대해서만 보여드렸는데, 동기/비동기에 따라서 방법이 달라집니다.
일반적으로 비동기로 다른 bounded context 간 통신을 하게 된다면 메시지큐에 이벤트를 넣어서 처리합니다.
동기로 처리한다면 REST API, GraphQL, gRPC 등 Bounded context 간 통신을 통해 요청을 합니다. 그런데 이것은 서로 다른 Bounded context가 각각의 서버에 배포되었을 경우이고 (그래서 총 2개의 서버) 만약에 2개의 bounded context가 하나의 서버에 배포가 되었다면 Repository를 사용해서 다른 bounded context의 정보를 가져올 수 있을 것입니다.
질문3)
주문 Entity - 주문 아이템 Entity 관계가 Aggregate 로 연상됩니다.
맞습니다
Bounded Context 개념이 적용된 코드가 Aggregate 쪽 코드와 다를까요?
Aggregate는 강의에서 Aggregate Root라는 구체적인 클래스로 현실 세계의 사물에 대한 것을 구현을 했습니다. 그런데 Bounded Context는 Aggregate에 반해서 추상적인 개념입니다. 그래서 Aggregate 처럼 class로 구체화되는 것이 아니라 강의에서처럼 영역을 그림으로 그려놓고 마이크로서비스 아키텍쳐를 사용한다면 서버를 분리한다든가 하는 것입니다.
한가지 예시를 더 들어서 설명을 드리겠습니다.
배달의 민족 서비스를 생각해보면, 그 시스템에 참여하는 사람의 종류는 세가지입니다. 음식점 사장, 배달시킨 사람, 배달원. 그런데 각각 참여자들의 머리 속엔 고객에 대한 추상화가 다르게 되어있을 것입니다.
음식점 사장님 머리 속에는 음식을 맛있게 만들어 드려야 하는 대상, 배달원 머리 속에는 사는 곳에 정확하게 배달해야 하는 대상. 그래서 같은 대상을 지칭하더라도 각자의 bounded context에서 회원은 Class가 다르게 구현이 되어있을 것입니다.
설명이 잘 되었는지 모르겠네요 🤔 질문이 있으시면 언제든 환영입니다 :)