Aggregate 설계
1. 바운디드 컨텍스트 정하기
의미적으로 동일한 컨텍스트의 범위
나는 일단 혼자서 이 프로젝트를 진행하고 있으므로 하나의 바운디드 컨텍스트만 가진다. ECommerce(온라인 거래) 하나의 바운디드 컨텍스트만 가진다.
2. 애그리거트 설정
나는 ECommerce라는 바운디드 컨텍스트 안에 들어갈 애그리거트를 다음과 같이 설정하였다.
1. 주문
2. 거래
3. 상품(상품 가격, 이름, 썸네일 등. 재고를 의미하지 않는다.)
4. 리뷰
5. 회원
핵심 도메인은 주문으로 보고 그 이하의 애그리거트는 하위 도메인으로 본다.
3. 시나리오 설정
혼자서 정말 ECommerce를 개발할 수는 없다. 따라서 한정된 시나리오를 완료해 보는 것으로 프로젝트를 진행하겠다.
1번 시나리오
상품 정보 조회(여러 Aggregate로 부터 필요한 데이터 조회)
상품정보 = 상품(이름, 가격, 썸네일), 리뷰(평균 평점)
2번 시나리오
주문 발생 -> 거래 발생, 회원 포인트 변경 ->
1. 거래 발생에서 거래 실패 시 회원 포인트 & 주문 정보 수정
4. 도메인 설계
편의상 Root Aggregate만 작성하겠다.
주문
ProductOrder
상품
Product
회원
Member
리뷰
Review
거래
Transact
통신 규약
사용 가능한 Protocol
- REST API
- gRPC
- kafka(messaging)
- REST의 경우 http를 기반으로 한 전통적인 통신 규약.
- gRPC의 경우 http2를 기반으로 한 protocol로 양방향 스트리밍과 성능(Header Compression, Multiplexed stream)이 REST와의 큰 차이점으로 볼 수 있다.
- Kafka의 경우 특정 프로콜이 아니라 Messaging 플랫폼으로 토픽이라는 것을 사용하여 메시지를 발행 및 구독할 수 있다.
사실 모든 로직이 구현이 불가능한 것은 아니지만 현재 상황(혹은 예상되는 상황)에 맞춰 적절한 방법을 택해야 한다.
내가 생각했을 때 REST는 Legacy라면 아직 완전히 뒤집어 엎는 수준이 아니라면 Protocol을 바꾸긴 쉽지 않다. 기존의 Protocol을 준수해야 하는 경우(Coupling이 강할 경우) 택해야 할 수 있을 것 같다.
Legacy 문제만 아니라면 gRPC는 좋은 선택이 될 수 있다. 기존의 Client-Server 구조를 따르고 있을 뿐 아니라 Server Push라는 좋은 기능을 사용할 수도 있기 때문이다. 심지어 성능도 더 좋다.
Kafka의 경우 만약 많은 MSA의 Component가 해당 서비스의 동작에 따라 뭔가 행동할 필요가 있다면 사용할 수 있는 좋은 플랫폼이다. 하지만 하나의 트랜잭션이 중간에 실패 했을 때 보상 트랜잭션을 만들어야 하기 때문에 다소 개발이 어려운 것이 사실이다.
예를들어 추천 서비스 구현을 위해 상품의 구매 이력을 가져온다고 하면 grpc를 사용하여 가져오면 된다. 혹은 유저의 채팅 목록, 계좌 정보 등등 자신의 데이터를 만들기 위해 다른 서비스의 데이터가 필요할 경우 grpc를 이용하여 조회하면 좋을 것이다.
하지만 주문 발생 -> 회원 정보 변경, 거래 데이터 생성, 추천 시스템 변경 이렇게 많은 서비스에 필요한 이벤트라면 Kafka를 이용하여 메시지를 발행하면 좋을 것이다.
