TIL - 숙련 프로젝트 종료 후, 주문 시나리오 설계 회고

주문 시나리오 설계의 변천사

프로젝트 발의문을 읽고 나서 주문 시나리오 설계에 대해서
초반 설계 당시의 생각부터 중간중간 설계를 바꾼 과정들을 돌아보려고 한다.

먼저 이번 프로젝트는 쿠팡과 같은 물류 대행업체의 백엔드 서비스를 만드는 것이었다.
그러러면 발주 주문 -> 배달 -> 수령으로 이어지는 시나리오를 작성해봐야 했다.

초기 프로젝트 요구사항 분석

초기 프로젝트 설계, 주문이 어떤순서로 생성되는가?

일단 우리팀은 몇가지 실제 서비스되는 환경을 고려해 몇 가지 요구사항을 추가했다.

1. 사용자가 주문을 하면, 해당 주문은 자정(00시)에 확정이 됩니다.
2. 확정된 주문서는 이벤트 발행 시, 메시지에 담아 보낸다.
3. 주문서를 받은 배송 서버는 배송 주문 1건에 대한 배송 경로를 생성한다.

이때, 하나의 배송에 대해서 출발지부터 도착지까지 한 명의 기사님이 운송하는것이 아니라
여러 명의 기사님이 나눠서 운송하게 되는 구조였기에 1 : N의 관계로 설정했습니다.

그럼 자연스럽게 주문서를 누가 생성하고,
배송은 누가, 어떤 경로로 가야하고
만들어진 배송 경로는 어디서 관리해야 할 지도 정해야했다.

숙련 프로젝트는 MSA 프로젝트였기에, 각 서버별로 책임의 경계를 설정하는 것이 중요했다.
그래서 아래와 같이 주문 시나리오를 서버별로 어떤 작업을 처리할지 정했었습니다.

주문 시나리오 구성

주문부터, 운송, 배달 완료까지의 시퀀스 다이어그램

먼저 누가 주문을 할지부터 결정했어야 했습니다.
수령 업체가 직접 할 수도 있고,
수령 업체 내부에 직원이 할 수도 있습니다.

수령업체가 직접 주문하는 경우에는 업체 서버에서 이벤트 발행을 해야 했고
수령업체 내부의 직원이 주문하는 경우에는 주문 서버에서 POST HTTP 요청을 받아야 했습니다.

어떻게 할 지 결정하지 못했기에,
위 2개의 경우를 다 상정하고 설계했습니다.

요청을 받은 주문서버는 주문을 생성하게 됩니다.
이 주문데이터는 자정에 확정되어 허브 서버로 주문 생성을 알리는 이벤트를 발행하게 됩니다.

허브 서버는 일종의 오케스트레이터로써,
주문서버로 부터 받은 '주문생성' 이벤트를 수신하여 주문서 정보를 받게되고,
또 허브에 소속된 배송 담당자에 대한 정보는
유저서버에 있었기에 FeignClient로 가져와서
배송 담당자 정보와 주문서를 취합해서 배송 서버로 보내줍니다.

마지막으로 배송 서버에서는 허브서버에서 받은 정보를 토대로
배송 데이터를 생성하고 관리하게 됩니다.

전체적인 시나리오는 이렇게 구성을 했고, 이후엔 주문 상태에 대해 고민했습니다.

원래는 배송이 완료되면 배송 서버에서 주문 서버에게 배송이 완료됐다는 이벤트를 발행했는데
SRP 측면에서, 주문 서버가 배송 관련 정보를 받게 되면 책임이 모호해진다 생각해서 주문 상태를 개편하게 됩니다.

아래는 최종 주문 시나리오입니다.

최종 주문 시나리오

주문 상태값에서 배송에 대한 상태값을 제외했다.

주문에서 관리하는 상태필드(ENUM 객체)를 변경했습니다.
오로지 주문 관련된 상태로만 구성해서 책임을 명확히 했습니다.

그리고 배송서버는 주문서버에게 더 이상 배송 관련 데이터를 보내지 않고
SAGA 패턴을 위한 실패를 알리는 이벤트만 발행합니다.

그렇게 주문 상태는 아래처럼 구성했습니다.

1. ORDER_CREATED       // 주문 생성
2. ORDER_CANCELLE     // 주문 취소 완료
3. ORDER_FIXED             // 주문 확정 ( 00시 이후 주문확정으로 변경 )
4. SYSTEM_CANCELLED // 배송중 문제가 생겨 사용자가 아닌 회사측 직원이 주문을 취소한 경우

그리고 AI 서버를 추가해 배송 담당자와 수령인들에게 업무 지시와, 도착 예정 시간을 슬랙 메시지로 알리도록 추가했습니다.

마무리)

비즈니스 요구사항 분석 시, 내가 실제 사용자가 되어 주문을 한다고 가정하여 시나리오를 구성해봤습니다.
이 과정은 주문 서버의 책임을 명확히 설정하고, 각 서버간 동기/비동기 요청 흐름을 구성할 때 많은 도움이 된 것 같습니다.