미션에 QueryDSL 적용

[robinjoon]

구현 요약

MissionRepository에 JPQL 사용하는 부분 QueryDSL로 대체

Member나 HashTag에는 QueryDSL 사용하는 부분이 없어서 변경 사항 없어요!

DB 접근 기술 변경이 Service 레이어의 변경이 필요한 건 어색하다고 생각해서 Repository에 추가 계층을 두었어요.

연관 이슈

• close 미션 & 해시태그 & 멤버 QueryDSL 적용 #605

참고

코드 리뷰에 RCA 룰을 적용할 시 참고해주세요.

헤더	설명
R (Request Changes)	적극적으로 반영을 고려해주세요
C (Comment)	웬만하면 반영해주세요
A (Approve)	반영해도 좋고, 넘어가도 좋습니다. 사소한 의견입니다.

[robinjoon]

이 방식의 장점과 단점을 추가로 정리해봤어요.

장점

application 패키지로 변경이 전파되지 않는다.

이 PR의 변경사항에서 확인할 수 있는 것 처럼, 데이터베이스 접근 기술의 변경으로 인한 코드 변경이 domain 패키지에만 존재합니다. 레이어드 아키텍처를 잘 따랐고 그 장점을 누렸다고 봅니다.

MissionRepositoryTest의 수정이 필요하지 않다.

이 PR의 변경사항에서 확인할 수 있는 것 처럼, 테스트를 새로 작성하거나 테스트 위치를 변경할 필요가 없습니다. MissionRepository의 테스트를 통해 내부 구성 요소 (QueryDslMissionRepository)의 테스트가 되기 때문입니다. 명확하게 하기 위해 QueryDslMissionRepository의 테스트를 추가한다면 이는 기존 테스트 코드를 단순 복사 붙여넣기로 활용할 수 있어요.

원한다면 QueryDSL를 점진적으로 도입할 수 있다.

이 PR에는 해당 사항이 없지만, 만약 어떤 쿼리가 QueryDSL로 작성하기 어려운 쿼리가 있었다면 이를 JpaMissionRepository 클래스에 기존 방식대로 JPQL을 이용해 작성한 코드를 유지할 수 있어요. MissionRepository의 메서드에서 JpaMissionRepository의 코드를 호출하게 하면 되니까요.

원한다면 application 레이어(Service)의 테스트에서 데이터베이스 종속을 제거할 수 있다.

application 레이어의 테스트에서 영속성 컨텍스트 문제로 인해 @Transactional 어노테이션을 추가한 것을 기억하실거에요. 이런 부분을 개선하는 방법 중 하나로 application 레이어의 테스트에서 실제 데이터베이스를 사용하지 않고 Fake 구현체를 사용하는 대안을 생각할 수 있어요.
기존 방식대로면 이는 엄두조차 나지 않을 거에요. JpaRepository의 수많은 메서드를 다 인메모리로 구현할 수 없으니까요. 그런데, 지금의 코드 처럼 MissionRepository에 우리가 사용하는 메서드를 직접 정의해주는 방식이라면, 합리적인 일이 될 수 있어요.

물론, 어디까지나 불가능했던 선택지가 가능한 선택지로 바뀐거지, 꼭 선택해야 할 선택지가 된 건 아니에요!

참고로 Fake의 구현은 MissionRepository을 상속하면 될거에요.

다른 데이터베이스 접근 기술을 추가 도입할 경우 점진적 도입이 가능하다.

QueryDSL과 마찬가지로 다른 데이터베이스 접근 기술 도입 시에도 CustomMissionRepository의 새로운 구현체를 추가하면 되기 때문에 점진적으로, 부분적으로 도입할 수 있어요.

단점

MissionRepository 클래스에도 메서드 추가 작업이 필요하다.

확장성의 대가로 약간의 메서드 추가 작업이 필요해요.

추가되는 클래스 개수가 더 많다.

CustomMissionRepository 인터페이스, QueryDslMissionRepository, JpaMissionRepository 의 추가와 MissionRepository의 일반 클래스화 작업이 필요해요.