[2 ~ 4 단계 방탈출 예약 결제 / 배포] 알파카(최휘용) 미션 제출합니다.

[slimsha2dy]

안녕하세요 피케이, 오랜만에 다시 리뷰를 부탁드리러 온 알파카입니다.
2단계에서 설계를 수정하기 위해 rollback을 몇 번 하느라 리뷰가 늦어지게 되었습니다.. 상세한 내용은 아래에 적어놓았습니다.
3단계 요구사항인 배포 과제는 제공받은 서버 문제로 인해 되지 않는 상황입니다. 해결되는 즉시 말씀드리겠습니다!
저번 pr에서 추가로 남긴 의견입니다.
이번 리뷰도 잘 부탁드립니다!

이번 미션에서 고민한 부분

설계에 대한 고민

결제 테이블과 예약 테이블의 관계, 그리고 저번 리뷰에서도 잠깐 언급했던 예약 대기와 결제의 연결에 대한 고민이 있었습니다.
결제와 예약은 서로 일대일 관계이지만 예약이 항상 결제를 갖고 있지는 않습니다(어드민이 예약을 추가한 경우).
따라서 예약이 결제를 알 경우 해당 column에 불필요한 null값들이 들어가게 되므로 굳이 양방향으로 선언할 필요가 없다고 생각했고, 이에 따라 결제에서만 예약을 알고 있도록 단방향 관계를 맺었습니다. 또한 만약 예약이 결제를 갖고 있는데 null일 경우, 엔티티이므로 여러 군데에서 이 null을 따로 처리해야 하므로 관리 비용도 클 것이라고 생각했습니다.
예약 대기와 결제의 경우, 예약으로 변경된 예약 대기를 결제 대기 상태로 놓고, 사용자가 예약 목록에서 결제를 할 수 있도록 적용하려 했었지만 이로 인해 수정하고 추가해야 하는 프론트 코드의 양이 많아 시간이 너무 오래 걸렸습니다.. 따라서 이번 미션에 집중하기 위해 해당 부분들은 rollback하게 되었습니다.

결제 데이터를 얼마나 저장할지

저번 리뷰에서 말씀드린 것처럼, 예약과 결제를 분리함으로써 얻을 수 있는 장점도 있을 뿐만 아니라 서로 다른 관심사를 갖고 있다고 생각해 도메인을 분리하게 되었고, 도메인이 다른 데이터는 서로 다른 테이블에 저장하는 것이 합리적이라고 생각해 두 테이블을 분리하게 되었습니다.
이에 따라 결제 테이블에 토스페이먼츠 API에서 반환하는 결제 데이터 중 어떤 데이터를 저장할까 고민해봤습니다. 기본적으로 paymentKey를 통해 결제 데이터를 조회할 수도 있고, 수많은 결제 데이터 중 지금 프로그램 규모에서 미리 고려해서 저장할 데이터는 없다고 생각했기 때문에, 미션의 요구사항에 필요한 데이터인 paymentKey, amount, 그리고 토스 API에서 구분자로 사용되는 orderId만 저장하도록 해봤습니다.

API 문서

Spring Rest Docs와 Swagger 중 고민해봤는데, Swagger의 경우 API 테스트 화면을 통해 사용자가 쉽게 API를 이해할 수 있고, 더 쉽게 적용할 수 있다는 장점이 크다고 생각해 선택하게 되었습니다.
서버를 실행한 후 localhost:8080/swagger-ui/index.html로 접속하면 확인하실 수 있습니다.

ERD

[slimsha2dy]

안녕하세요 피케이, 오랜만에 다시 리뷰를 부탁드리러 온 알파카입니다. 2단계에서 설계를 수정하기 위해 rollback을 몇 번 하느라 리뷰가 늦어지게 되었습니다.. 상세한 내용은 아래에 적어놓았습니다. 3단계 요구사항인 배포 과제는 제공받은 서버 문제로 인해 되지 않는 상황입니다. 해결되는 즉시 말씀드리겠습니다! 저번 pr에서 추가로 남긴 의견입니다. 이번 리뷰도 잘 부탁드립니다!

이번 미션에서 고민한 부분

설계에 대한 고민

결제 테이블과 예약 테이블의 관계, 그리고 저번 리뷰에서도 잠깐 언급했던 예약 대기와 결제의 연결에 대한 고민이 있었습니다. 결제와 예약은 서로 일대일 관계이지만 예약이 항상 결제를 갖고 있지는 않습니다(어드민이 예약을 추가한 경우). 따라서 예약이 결제를 알 경우 해당 column에 불필요한 null값들이 들어가게 되므로 굳이 양방향으로 선언할 필요가 없다고 생각했고, 이에 따라 결제에서만 예약을 알고 있도록 단방향 관계를 맺었습니다. 또한 만약 예약이 결제를 갖고 있는데 null일 경우, 엔티티이므로 여러 군데에서 이 null을 따로 처리해야 하므로 관리 비용도 클 것이라고 생각했습니다. 예약 대기와 결제의 경우, 예약으로 변경된 예약 대기를 결제 대기 상태로 놓고, 사용자가 예약 목록에서 결제를 할 수 있도록 적용하려 했었지만 이로 인해 수정하고 추가해야 하는 프론트 코드의 양이 많아 시간이 너무 오래 걸렸습니다.. 따라서 이번 미션에 집중하기 위해 해당 부분들은 rollback하게 되었습니다.

결제 데이터를 얼마나 저장할지

저번 리뷰에서 말씀드린 것처럼, 예약과 결제를 분리함으로써 얻을 수 있는 장점도 있을 뿐만 아니라 서로 다른 관심사를 갖고 있다고 생각해 도메인을 분리하게 되었고, 도메인이 다른 데이터는 서로 다른 테이블에 저장하는 것이 합리적이라고 생각해 두 테이블을 분리하게 되었습니다. 이에 따라 결제 테이블에 토스페이먼츠 API에서 반환하는 결제 데이터 중 어떤 데이터를 저장할까 고민해봤습니다. 기본적으로 paymentKey를 통해 결제 데이터를 조회할 수도 있고, 수많은 결제 데이터 중 지금 프로그램 규모에서 미리 고려해서 저장할 데이터는 없다고 생각했기 때문에, 미션의 요구사항에 필요한 데이터인 paymentKey, amount, 그리고 토스 API에서 구분자로 사용되는 orderId만 저장하도록 해봤습니다.

API 문서

Spring Rest Docs와 Swagger 중 고민해봤는데, Swagger의 경우 API 테스트 화면을 통해 사용자가 쉽게 API를 이해할 수 있고, 더 쉽게 적용할 수 있다는 장점이 크다고 생각해 선택하게 되었습니다. 서버를 실행한 후 localhost:8080/swagger-ui/index.html로 접속하면 확인하실 수 있습니다.

ERD