STEP 6: 프로젝트 ERD, API 명세서, Mock API 구현 #2
Conversation
| ### 3. 예약 가능 좌석 조회 API | ||
|
|
||
| #### Request | ||
|
|
||
| - **URL**: `/api/v1/concert-schedules/{scheduleId}/available-seats` | ||
| - **Method**: `GET` | ||
| - **Headers**: | ||
| - Content-Type: application/json | ||
| - X-Queue-Token: [대기열 토큰] | ||
| - **Path Parameters**: | ||
| - `scheduleId`: `Integer` | ||
|
|
||
| #### Response | ||
|
|
||
| - **Status Code**: 200 OK | ||
| ```json | ||
| { | ||
| "concertSeats": [ | ||
| { | ||
| "id": "Integer", | ||
| "concertScheduleId": "Integer", | ||
| "number": "Integer", | ||
| "price": "Integer", | ||
| "isReserved": "Boolean" | ||
| } | ||
| ] | ||
| } | ||
| ``` |
There was a problem hiding this comment.
어떤 방식이 restful 할까? 이 고민을 많이 했던 것 같습니다.
이전에는 중첩구조를 고집하여 긴 url 작성하는 것에 습관이 있었습니다. e.g GET: /api/v1/concerts/{concertId}/concertSchedules/{concertScheduleId}/concertSeats?isAvailable=true
하지만 이게 과연 restful할까 라는 고민을 했을때 도메인간의 계층 관계는 보이긴하지만 이렇게 긴 url로 표현을 해줄 필요가 있을까? 라는 고민이 들었고 중첩보단 flat을 활용할려고 했습니다.
이게 과연 Restful 한지 아니면 더 좋은 방법이 있는지 해당 API 말고도 다른 API 들도 리뷰 부탁드립니다.
docs/ERD.md
Outdated
| Reservation { | ||
| Long id PK "AUTO_INCREMENT" | ||
| Long concert_seat_id FK | ||
| Long user_id FK | ||
| Enum status "WAITING, CONFIRMED, CANCELED" | ||
| Datetime reserved_at | ||
| } | ||
|
|
||
| Payment { | ||
| Long id PK "AUTO_INCREMENT" | ||
| Long reservation_id FK | ||
| Long user_id FK | ||
| Long amount | ||
| } |
There was a problem hiding this comment.
Reservation, Payment 애내는 각자의 독립적인 도메인인가? 라고 생각했을때 지금 테이블 구조로는 Reservation은 Concert에 의존하고 있고 Payment는 Reservation에 의존하고 있다라고 생각했습니다.
그래서 별도의 독립적인 도메인이 아닌 서브도메인으로 고려했습니다.
이렇게 생각한 부분이 맞는지 궁급하니다.
그리고 그럼 Reservation, Payment의 테이블 구조를 독립적인 도메인 구조로 바꾸면 되지않나? 라고 생각했을 땐
가능은 하겠지만 지금 요구사항에서 너무 오버엔지니어링 하는게 아닐까? 라는 생각이 들어 현 ERD 상태가 되었습니다. 이부분도 의견주시면 감사하겠습니다!
There was a problem hiding this comment.
저도 비슷한 고민을 했었습니다. 예약 같은 경우, 서비스내에 예약이라는게 전시도 있고, 콘서트도 있고 다양한 도메인을 예약할 수 있는 구조라면 저는 예약을 별도의 도메인으로 분리할 것 같다라고 생각했습니다. 허나 현재 요구사항만을 보면 콘서트만 예약을 하는걸로 이해해서 콘서트 하위에 예약 도메인을 뒀습니다. 추후 확장성을 고려한다면 예약 도메인이 별도로 생성되는게 맞는 것 같습니다.
위와 같이 생각했을때, 결제가 반드시 예약만 한다고 발생하는게 아니라, 충전, 다른 상품 구매가 발생했을 때도 결제가 이뤄진다고 생각해보면 결제 도메인도 별도로 빠지는게 맞다고 생각합니다.
그리고 데이터 관점보다는 실세계에 빗대어서 도메인간의 관계를 생각해보면 관계를 정리하는데 좀 더 명확해지는 것 같았습니다.
| import org.springframework.boot.autoconfigure.SpringBootApplication; | ||
| import org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration; | ||
|
|
||
| @SpringBootApplication(exclude = {DataSourceAutoConfiguration.class}) |
There was a problem hiding this comment.
현재 DB가 구현되지않아서 추가된 부분입니다. 참고차 남깁니다.
| @@ -0,0 +1,12 @@ | |||
| package com.example.hhplus.concert.domain.concert.model; | |||
There was a problem hiding this comment.
mock api를 만드는 과정에서 mock api의 response type들이 도메인 모델을 그대로 사용하는 부분이 많아 필요한 도메인 모델만 작성했습니다. mock api를 만들때 이렇게 도메인 모델을 같이 만들어도 괜찮을까요?
| @@ -0,0 +1,7 @@ | |||
| package com.example.hhplus.concert.domain.concert.model; | |||
|
|
|||
| public enum ReservationStatus { | |||
There was a problem hiding this comment.
도메인 모델의 enum type들을 model 패키지에 넣는게 맞을까? 라는 의문이 들었는데 리뷰어 분들의 의견도 듣고 싶습니다.
There was a problem hiding this comment.
model 패키지에서 사용되는 enum이라면 저는 보통 model에 추가하는 편입니다.
- db type으로 변경 - 테이블명 소문자, snake case로 변경 - enum type -> varchar로 변경
|
이번 한주도 수고 많으셨습니다 👍 |
요구사항
변경 사항
리뷰포인트