프로젝트 세팅_황인영 #3
프로젝트 세팅_황인영 #3
Conversation
There was a problem hiding this comment.
ScheduleReq, ScheduleResp는 core layer 하위로 옮겨도 될 것 같아요.
schedlue>application>Service>impl 은 datasource 아래로 옮겨도 될 것 같아요
schedule>application>Servcie>scheduleService는 core layer 하위로 옮기는게 좋아보여요!
그리고 application layer대신 core라고 이름 바꿔주시면 될 것 같아요!
마지막으로..! schedule layer가 전체적인 일정 말씀하시는거죠? 얘가 application/datasource/presentation layer보다 상위에 있으면 안됩니다! 따라서 없애주세요!
| import org.springframework.boot.autoconfigure.SpringBootApplication; | ||
|
|
||
| @SpringBootApplication | ||
| public class CatcheApplication { |
There was a problem hiding this comment.
| public class CatcheApplication { | |
| public class CatcherApplication { |
There was a problem hiding this comment.
service impl이 비즈니스 로직을 구현하는 클래스여서 core(이전 application) 하위로 넣었는데, 혹시 왜 impl이 datasouce 로 옮겨져야 하는지 설명부탁드려도 될까요? 😭
There was a problem hiding this comment.
아 Impl도 Core에 있어도 상관은 없지만 만약 Impl을 구현하는 과정중에 Core에선 몰라야 하는 상세 DB와 같은 것들이 있을까봐 말씀드렸었어요! 없다고 생각하신다면 Impl도 전부 Core에서 구현하고 이외 제가 말씀드린것 같은 특이사항이 있는 경우 Datasource layer에 구현해도 될 것 같아요ㅎㅎ
| @@ -0,0 +1,13 @@ | |||
| package server.catche; | |||
There was a problem hiding this comment.
| package server.catche; | |
| package server.catcher; |
| request.getEndDate() | ||
| ); | ||
| scheduleService.registerSchedule(schedule); | ||
| return null; |
There was a problem hiding this comment.
제네릭 타입때문에 null은 던져주는게 이뻐보이진 않네요 흠...ㅋㅋㅋ
There was a problem hiding this comment.
끄악ㅠ 저도 너무 거슬리는 부분인데요.. 반환값을 던져주어야 하는 상황에서는 command 패턴을 어떻게 사용하나요? 다른 좋은 방법이 있을 것 같은데.. 🥲
There was a problem hiding this comment.
저도 찾아보곤 있는데 결과적으론 다 null을 던져주는것 처럼 보여서 전 팀원들한테도 물어보고 있어요!
There was a problem hiding this comment.
아니면 Optional로 한번 감싸서 던져주는건 어떨까요? null 값이 아니라 Optional.empty로..? 하지만 그럼 모든 반환값이 또 감싸져서 나와야하고.. 🤔
There was a problem hiding this comment.
ㅋㅋㅋ맞아요. 일단은 이렇게 두고 더 나은 방법이 있으면 리팩토링 하는 방안으로 진행하죠ㅎㅎ
| @Transactional(readOnly = true) | ||
| public ScheduleResp.ScheduleDTO getSchedule(Long scheduleId) { | ||
| Schedule schedule = scheduleRepository.findById(scheduleId) | ||
| .orElseThrow(); |
There was a problem hiding this comment.
여기도 커스텀 예외 하나 만들어야할것 같긴하네요
| @RequestBody ScheduleReq.ScheduleRegisterDTO request | ||
| ) { | ||
| Command<Void> command = new RegisterScheduleCommand(scheduleService, request); | ||
| command.execute(); |
There was a problem hiding this comment.
이런 부분에서 commandExecutor를 호출하고 commandExecutor 내부에서 execute()가 동작해야 해요!
There was a problem hiding this comment.
execute()를 한번더 감싸주기 위해서인가요? Command를 executor에 넘기고 executor내부에서 execute()가 동작해야한다는 말씀이시죠?
There was a problem hiding this comment.
네 맞아요! CommandExecutor에선 어떤 subtype의 Command가 오는것을 몰라도 되는 상태로 ~~command.execute() 만으로 정상 동작이 수행돼야 한다 라고 보시면 될것 같아요.
|
|
||
| @NotBlank | ||
| private String content; | ||
| private String thumbnail; |
There was a problem hiding this comment.
| private String thumbnail; | |
| private String thumbnailUrl; |
| private String thumbnail; | ||
|
|
||
| @DateTimeFormat(iso = DateTimeFormat.ISO.DATE) | ||
| private LocalDate startDate; |
There was a problem hiding this comment.
위 이유로 ZonedDateTime으로 하죠!ㅎㅎ
There was a problem hiding this comment.
오 zonedDateTime은 사용해본적이 없는데, 공부해서 리팩토링해보겠습니다. 👍
|
동등한 layer가 app, core, resource(presentation), datasource? 정도 있으면 될것 같아요! domain은 따로 둬도 되고 혹은 resource layer 하위에 넣으면 될것 같습니다 |
| @Slf4j | ||
| @RestController | ||
| @RequiredArgsConstructor | ||
| @RequestMapping("/api/schedule") |
There was a problem hiding this comment.
모두 컨트롤러로 들어오는 모든 요청이 api일텐데 해당 prefix를 붙이는게 의미가 있을까요..?
*command 패턴 사용하신다고 하셔서 적용해보려고 했습니다! 이게 맞는지는 잘 모르겠지만..