TIL - 주문 테이블 구조 의사 결정 과정

우리 팀은 프로젝트 발의문엔 없지만 실제 이커머스 서비스를 고려해서

00시가 되면 주문이 확정 주문으로 변경하고
배송 서버에 이벤트를 발행하기로 했다.

 

그에 따라 주문의 상태가 00시 전 후로
가주문과 확정 주문으로 나뉘는 데

00시 전에는 사용자가 주문을 취소하거나 변경할 수 있고,
00시가 되면 취소 or 변경이 불가능하도록 설정하려 한다.
그리고 00시에 주문이 확정되면, 허브 배송 담당자에게 슬랙 메시지를 보내고
06시까지 모든 허브에 물건을 배송하도록 하고

06시부터 업체 배송 담당자에게 각 수령 업체로 배달을 한다고 설정했다.

그래서!
주문 테이블을 가주문 테이블과 확정 주문 테이블로 분리해서 관리할 것 인지,
주문 확정 여부를 ENUM 타입을 사용하고 상태 값으로써 관리할 것 인지,
아니면 단순히 별도의 boolean 필드를 추가해 주문 확정 여부를 true, false로 관리할 것인 지 정해야 했다.

주문 상태를 ENUM으로 관리하고, boolean 필드로 주문 확정 여부만 관리하기로 했었다.

의사 결정 과정을 적어보았다.

 

1. 처음엔 주문을 가주문과 확정 주문테이블로 나눠서 관리하기로 생각했다.
2. 관리의 복잡성이 증가하고, 중복 필드가 많아서 가주문과 확정 주문을 하나의 주문 테이블에서 관리하기로 결정했다.
3. ENUM 값을 조회하면 성능면에서 안 좋다고 생각해
is_fixed_order라는 boolean 필드로 확정 주문인 지 여부를 판단하기 결정했다.

여기까지 생각하고, 다시 튜터님께 피드백을 받아봤다.

주문 확정 여부에 대한 상태도 ENUM으로 관리하라고 피드백 받았다.

튜터님께서 꼭 boolean 필드가 필요하지 않아 보인다고 하셔서, 모든 주문 상태를 ENUM으로 관리하라고 피드백 주셨다.

최종적으로 ENUM으로 모든 주문 상태를 관리하고, 주문 상태에 대한 자세한 설명을 적었다.

4. ENUM과 일반 boolean 필드간의 차이가 별로 안나는 것 같아서

order_status에서 확정 주문에 대한 상태도 관리하기로 최종 결정했다.
- 각 상태별로 어떤 행동의 결과를 저장하는 지 설명을 적었다.