[Refactor] 도메인 패키지 구조로 리팩토링

[packdev937]

이슈 번호

#83

같이 의논해보면 좋을 사항

• dto 클래스는 어디까지 노출하는게 좋을까?

리팩토링 진행 상황

• menu
• report
• user
• restaurant
• inquiry
• mypage
• review

주요 변경 사항

Menu

MenuController을 MenuController와 MealController로 분리하였습니다.

• MealController는 식단과 관련된 API들을 모아놓았습니다. (식단 추가, 식단 조회, 식단 삭제)
• MenuController에는 메뉴와 관련된 API들을 모아놓았습니다. (메뉴 조회, 메뉴 정보 리스트 조회)

Menu 도메인 패키지를 새로 생성하였습니다.

└ menu
    └ dto
    └ entity
    └ presentation
    └ service
    └ repository

책임을 변경하였습니다.

 @GetMapping("/fix-menu")
    public BaseResponse<List<FixMenuInfo>> getFixMenuList(@Parameter(description = "식당이름")
                                                    @RequestParam("restaurant") RestaurantName restaurantName) {
        if(MenuType.isChanged(restaurantName)) {
            throw new BaseException(NOT_SUPPORT_RESTAURANT);
        }

        return BaseResponse.success(menuService.findFixMenuList(restaurantName));
    }

기존에는 MenuType에 해당 레스토랑이 변동 메뉴를 제공하는지, 고정 메뉴를 제공하는지 확인하였습니다.
하지만 이는 RestaurantName에서 확인하는 것이 맞다고 판단되었습니다.

변경 안은 다음과 같습니다.

 @GetMapping("/list")
    public BaseResponse<List<FixMenuInfo>> getMenus(
        @RequestParam("restaurant") RestaurantName restaurantName) {
        if (RestaurantName.isVariable(restaurantName)) {
            throw new BaseException(NOT_SUPPORT_RESTAURANT);
        }
        return BaseResponse.success(menuService.findMenus(restaurantName));
    }

전체적인 API 호출 경로 및 네이밍을 리팩토링 했습니다.

Report

ReviewReport 를 Report로 변경하였습니다.

SecurityUtil를 사용하는 것이 아닌 CustomUserDetails에서 id를 받아오도록 수정하였습니다.

public BaseResponse<Void> reportReview(@RequestBody CreateReportRequest createReportRequest,
        @AuthenticationPrincipal CustomUserDetails customUserDetails) {
        Report report = reportService.report(customUserDetails, createReportRequest);
        slackService
        ...
}

비즈니스 로직을 Service Layer로 위임하였습니다.

  @Operation(summary = "리뷰 신고 사유 종류 조회", description = "리뷰 신고 사유 종류를 조회하는 API 입니다.")
    @GetMapping("/type")
    public BaseResponse<ReportTypeResponse> getReportType() {
        return BaseResponse.success(reportService.getReportType());
    }

Inquiry

Repory와 마찬가지로 네이밍 변경과 CustomUserDetails를 받아서 유저를 조회하도록 리팩토링 하였습니다.

MyPage

해당 로직들은 UserController, UserService, SliceService에서 책임을 분산해서 맡도록 리팩토링 하였습니다.

별도의 SliceService를 만들었으며 Pageable 객체가 (거의) 고정 값이기 때문에 로직을 다음과 같이 수정했습니다.

public SliceResponse<MyReviewDetail> findMyReviews(
        CustomUserDetails userDetails,
        Pageable pageable,
        Long lastReviewId) {

        User user = userRepository.findById(userDetails.getId())
            .orElseThrow(() -> new BaseException(NOT_FOUND_USER));

        Slice<Review> sliceReviews = reviewRepository.findByUserOrderByIdDesc(user, lastReviewId,
            pageable);

        return convertToMyReviewDetail(sliceReviews);
    }

    private SliceResponse<MyReviewDetail> convertToMyReviewDetail(Slice<Review> sliceReviews) {
        List<MyReviewDetail> myReviewDetails = sliceReviews.getContent().stream()
            .map(MyReviewDetail::from)
            .collect(Collectors.toList());

        return SliceResponse.<MyReviewDetail>builder()
            .numberOfElements(sliceReviews.getNumberOfElements())
            .hasNext(sliceReviews.hasNext())
            .dataList(myReviewDetails)
            .build();
    }

Review

Slice 관련 로직을 SliceService로 리팩토링 했습니다.

[SY2on]

meal이랑 menu랑 한 클래스에 섞인 점이 항상 거슬렸는데 controller 분리하신거 아주 좋아요!

[SY2on]

SecurityUtil이 아닌 customUserDetails로 바꾼 이유가 있나요?

[SY2on]

dto의 범위가 dto를 web, repository 두군데서 사용하는 부분을 말씀하시는 거라면

저의 생각은 웹에서 사용하는 dto / queryProjection에서 사용하는 dto 를 구분(패키지를 분리하는 등)해서 해당 영역에서 사용하는게 좋아보입니다!

웹에서 요구하는 response가 달라졌을때 그게 해당 dto를 사용하는 repository 속 메소드에 영향이 갈 수도 있으니까 web용 dto 딱! repository용 dto 딱! 구분하면 섞일 일 없이 각자의 자리에서 사용되지 않을까요?