티켓 예매사이트 ERD, API 명세서 구현하기

티켓 예매사이트를 만드는 개인과제가 시작되었다. Typescript와 Nest.js를 배우고 처음으로 진행하는 과제라 잘 할 수 있을지 고민되지만, 하나씩 차근차근 진행해보려한다. 우선 ERD와 API 명세서를 구현하였다. 어느정도 이 두가지에 대한 이해가 생긴 후로는 처음으로 혼자서 만드는 것이었기에 고민된느 부분이 많았다.

 

ERD

https://drawsql.app/teams/strong-2/diagrams/ticket

 

고민되었던 부분은 필수구현 기능으로 있는 것들 안에서도 내가 어느정도까지 구현해야하는지 였다.

 

-인증/인가/사용자

 

이 부분에서는 token과 points_log 테이블이 고민되었다.

첫번째는 필수 구현에는 그냥 로그인 기능이라고 나와있었는데, 내가 욕심을 내서 refresh token까지 구현을 할 것인지였다. 이전과 같이 Javascript에 Express를 사용할 때였으면 당연히 했을 것인데, 새로운 언어로 구현하는 것이 어떻게 진행될지 몰라 고민하게되었다.

두번째는 point관련 부분이다. 우선은 쓴것인지 충전을 한 것인지를 쉽게 구분할 수 있는 type과 거래 points를 확인할 수 있도록 칼럼을 구성하였다. 

이게 욕심을 부리면 끝도 없이 부릴 수 있기 때문에 내 수준에 맞춰서 과제 제출 기한에 제출할 수 있도록 만들 수 있는 선을 조절해야했다.

 

 

- 공연 / 예매

여기서 고민 되었던 부분은 공연 일정이다. 공연같은 경우 같은 공연을 일자, 시간별로 여러번 하는 경우가 많기 때문에 배열로 사용할 수 있도록 schedules 테이블을 따로 빼주었다.

그리고 좌석수와 포인트 부분이 고민되었는데, 좌석 관련해서는 전체 좌석, 남은좌석, 예매한 좌석수 이렇게 세가지로 나눠주었다.  포인트는 가격, 지불한 총 포인트 두가지로 나눠주었다. 고민되고 어렵다고 생각한 이유는 둘다 transaction이 필요한 부분이고 직접 처음부터 구상해서는 처음 진행해보기 때문에 이게 맞는지 꽤나 고민되었다.

 

진행하다보면 수정해야할 일이 불가피하게 발생할 것 같긴하나, 우선은 이렇게 구상하고 시작하기로 하였다.

 

API 명세서

명세서 부분에서는 티켓 예매 부분이 고민되었다.

 

필요로하는 performanceId를 어디서 가져오느냐가 고민되었던 부분이다. parameters에서 가져오느냐, body에서 가져오느냐의 문제였는데, RESTful API 설계 원칙 그리고 url 경로구조의 일관성, 리소스간의 관계를 명확히 하기 위해 parameters에서 가져오기로했다. 예매 조회, 예매 취소도 동일한이유로 공연ID를 parameters에 모두 넣어주었다.

 

아직 erd와 api명세서를 설계할때 고민되는 부분이 많다. 최대한 고려하고 완성 후 시작해도 수정사항이 나올것이지만, 최대한 많이 경험해봄으로써 추후 수정사항을 점점 줄여가는것이 목표이다.