[Feature] - 여행 계획 작성 API 구현 #50
Conversation
| public class BadRequestException extends RuntimeException { | ||
|
|
||
| public BadRequestException(String message) { | ||
| super(message); | ||
| } |
There was a problem hiding this comment.
cause와 message를 함께 받는 생성자도 열어두심이 어떨까요?
필요할 때 열 수도 있을 것 같지만 stack trace 타는 것이 예외의 기본적인 성질이라고 생각해서요..!
There was a problem hiding this comment.
BadRequestException은 개발자가 직접 던지는 거라 cause를 추적할 일이 별로 없을 거라 생각합니다!
필요할 때 여는 방향으로 갈게용. 좋은 의견 👍
|
|
||
| public void validateStartDate() { | ||
| if (startDate.isBefore(LocalDate.now())) { | ||
| throw new BadRequestException("지난 날짜에 대한 계획은 작성할 수 없습니다."); | ||
| } |
There was a problem hiding this comment.
검증이 도메인 내에서 실행되고 있지 않고 서비스에서 호출되고 있군요.
검증 로직 자체가 서비스에 있다면 메서드의 이름과 특성을 바꾸는 것은 어떤가요.
- ex ) boolean isPastTravelPlan()
이를 기반으로 서비스에서 반환값을 확인하고 예외 상황을 컨트롤 하는 것이 좋아보여요
서비스에서 검증 로직을 확인하려면 도메인으로 이동해야 하니 로직이 한 눈에 들어오지 않을 것 같습니다.
이름 상 도메인 내에서 검증을 하는 것인지 헷갈릴 것 같기도 하고요!
There was a problem hiding this comment.
현구막이 미션 진행 중에 달아줬던 리뷰가 있었는데요, 서비스에서 요구사항이 변경됐을 때(Ex. 지난 날짜에 대한 정책이 지난 7일전과 같이 구체화 된다거나..) 가장 먼저 열어볼 곳은 domain이라는 리뷰가 있었습니다. 또한 평문적으로 읽었을 때도 travelPlan의 시작 날짜를 검증하는구나가 자연스럽게 읽히기 때문에 위의 형식을 사용했습니다. 좋은 제안 감사해용 리비~
| @PostMapping | ||
| public ResponseEntity<TravelPlanCreateResponse> createTravelPlan(@Valid @RequestBody TravelPlanCreateRequest request) { | ||
| TravelPlanCreateResponse data = travelPlanService.createTravelPlan(request); | ||
| return ResponseEntity.ok().body(data); |
| @Min(value = 0, message = "날짜는 1 이상이어야 합니다.") | ||
| int day, | ||
| @Schema(description = "여행 장소 정보") | ||
| @NotNull(message = "여행 장소 정보는 비어있을 수 없습니다.") List<PlanPlaceCreateRequest> places |
There was a problem hiding this comment.
PlanPlaceCreateRequest의 order 값들이 연속되지 않았는지 검증하는 로직이 추가되면 좋을 것 같습니다!
예를들어 1, 3, 4, 5 로 들어오는 경우요!
There was a problem hiding this comment.
지금 order의 경우 값 자체가 중요하기 보다는 순서 보장을 위해 사용되고 있어서 연속된 숫자 검증에 대한 필요성이 잘 느껴지지 않습니다! 들어올 때마다 반복문을 사용해서 검증하는 만큼 리소스가 들텐데 최적화할 수 있는 방법을 좀 더 생각해보겠습니다 👍
* feat: TravelPlan 관련 Entity 추가 * feat: 여행기 작성 API 구현 * feat: swagger 설명 추가 * feat: 여행 계획 작성 시 지난 날짜에 대한 검증 추가 * refactor: TravelPlanService method 분리 * refactor: PlanPlaceRequest에 toPlace 추가 * style: TravelPlanControllere 개행 정리
* feat: TravelPlan 관련 Entity 추가 * feat: 여행기 작성 API 구현 * feat: swagger 설명 추가 * feat: 여행 계획 작성 시 지난 날짜에 대한 검증 추가 * refactor: TravelPlanService method 분리 * refactor: PlanPlaceRequest에 toPlace 추가 * style: TravelPlanControllere 개행 정리
✅ 작업 내용
📸 스크린샷
🙈 참고 사항