다이어리 도메인 파사드 패턴 도입

[sapiens2000]

📌 PR 제목

다이어리 도메인 파사드 패턴 도입

✨ 변경 사항

• DiaryFacade 클래스 추가
• DiaryFacade 테스트 추가 (예정)
• DiaryServiceTest 수정
• LikeService 수정

🔍 변경 이유

기존의 코드 베이스 에서는 한 도메인의 서비스가 다른 도메인의 서비스를 호출하기 위해서

1. 필요한 기능이 존재하는 다른 서비스를 주입받아 호출
2. 레포지토리에서 직접 데이터 조회 후 가공

위 두 가지 방법을 혼용해서 썼습니다.

이러한 방식의 문제점은 다음과 같습니다.

1. 서비스가 서비스 호출하는 경우 의존성 관계가 복잡해져 잠재적 순환 참조 오류
2. 자신의 도메인이 아닌 외부 레포지토리에서 직접 조회해서 가공 하는 것이 서비스 도메인 역할에 맞지 않음

따라서 파사드 클래스를 도입해 해결하고자 하였습니다.

파사드 클래스는 사용자 관점에서의 유즈 케이스에 관심사를 두어서,
파사드 클래스에 대한 테스트를 수행하는 것이 곧 유즈케이스에 대한 통합 테스트를 수행하는 것이 되도록 했습니다.

서비스 리팩토링 시 관심사는 다음과 같았습니다.

1. 한 서비스가 외부 서비스, 레포지토리 의존을 최소화해서 단일 기능에 집중.
2. 서비스에서 서비스 의존은 되도록 하지말고, 필요하면 레포지토리 의존할 것
3. 해당 도메인에 대한 검증 로직(각 도메인에 맞는 Exception 발생이 필요한 경우) 은 서비스 레이어에서 수행.

파사드 클래스는 이러한 방식으로 설계된 서비스 코드들의 흐름을 조합, 제어해서
각 유즈케이스에 따른 원하는 결과를 도출하도록 작성했습니다.

✅ 체크리스트

• 코드가 정상적으로 동작하는지 확인
• 관련 테스트 코드 작성 및 통과 여부 확인
• 문서화(README 등) 필요 여부 확인 및 반영
• 리뷰어가 알아야 할 사항 추가 설명

📸 스크린샷 (선택)

📌 참고 사항

[sonarqubecloud]

Quality Gate passed

Issues
3 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[github-actions]

Claude의 전체 변경사항 및 관련 파일에 대한 리뷰:

개선된 사항:

• DiaryFacade 클래스 도입으로 비즈니스 로직의 복잡성이 감소하고 책임 분리가 개선되었습니다.
• DiaryService에서 불필요한 의존성(MapService)이 제거되었습니다.
• 테스트 코드가 새로운 구조에 맞게 업데이트되었습니다.

주요 이슈:

1. DiaryFacade의 오류 처리

   • 제안: 트랜잭션 관리와 예외 처리를 강화하세요.

   @Transactional
   public void createDiary(Long userId, DiaryRequestDto request) {
       try {
           String thumbnailUrl = mediaService.extractThumbnailUrl(request.mediaList());
           Diary diary = diaryService.saveDiary(userId, request, thumbnailUrl);
           mediaService.saveMedia(diary.getDiaryId(), request.mediaList());
           mapService.increaseRegionDiaryCount(request.location().latitude(), request.location().longitude());
       } catch (Exception e) {
           // 로깅 및 적절한 예외 처리
           throw new DiaryCreationException("다이어리 생성 중 오류 발생", e);
       }
   }

2. DiaryService의 메서드 명명

   • 제안: 메서드 이름을 더 명확하게 변경하세요.

   // 변경 전
   public Diary getDiaryAfterValidateOwnership(Long diaryId, Long userId)
   // 변경 후
   public Diary validateAndGetDiaryByOwner(Long diaryId, Long userId)

3. DiaryController의 응답 형식

   • 제안: 일관된 응답 형식을 사용하세요.

   @PostMapping
   public ResponseEntity<ApiResponse<Void>> createDiary(...) {
       diaryFacade.createDiary(customOAuth2User.getUserId(), request);
       return ResponseEntity.status(HttpStatus.CREATED)
           .body(ApiResponse.success(null, "다이어리가 성공적으로 생성되었습니다."));
   }

관련 파일에 대한 영향 분석:

• LikeService: DiaryFacade에서 사용되므로, LikeService의 변경이 DiaryFacade에 영향을 줄 수 있습니다.
• DiaryService: 여러 다른 서비스(MyPageService, CommentService 등)에서 사용되므로, 이들 서비스의 수정이 필요할 수 있습니다.
• DiaryController: API 응답 형식 변경 시 프론트엔드 코드 수정이 필요할 수 있습니다.

전반적인 의견:
파사드 패턴 도입으로 코드 구조가 개선되었습니다. 하지만 오류 처리, 명명 규칙, 응답 형식의 일관성 등에 주의를 기울여야 합니다. 또한, 관련 서비스들의 연쇄적인 수정 필요성을 고려해야 합니다.