Repository Interface에 default method 사용 논의

[kmebin]

예를 들어 MemberRepository에서 memberId를 통해 Member 엔티티를 조회하는 상황을 가정했을 때, 해당 회원이 존재하지 않는 경우 validate를 어디서 하면 좋을지에 대해 논의하지 않은 것 같아서 올립니다.

기존에는 아래 2가지 방법 중 하나를 사용했었습니다.

1. MemberService에서 validate를 하고, 다른 Service에서 Member를 조회할 때 MemberService를 주입 받아 사용
2. 각 Service에서 MemberRepository를 주입 받아, validate 함수를 중복해서 생성

다른 레퍼런스를 찾아보다가 3. Repository Interface에 default method를 사용하는 방식이 좋아보여 논의해보고 싶습니다!

• validate 함수를 중복해서 생성할 필요도 없고, MemberService 대신 MemberRepository를 주입하면 됩니다.

public interface MemberRepository extends JpaRepository<Member, Long> {

	default Member getById(Long id) {
		return findById(id).orElseThrow(() -> new NotFoundException(MEMBER_NOT_FOUND));
	}
}

1, 2, 3번 중 어떤 방식으로 진행하면 좋을지 각자 의견 부탁드려요! 🤗

[parksey]

잘 읽었습니다.

저는 MemberService처럼 서비스를 가져온다는 것 자체에 저는 이점이 있다고 생각합니다.
서비스를 가져오게 되면 그 서비스의 다른 기능까지 같이 사용할 수 있게 되는데,
서비스가 많아지면 ~Repostiroy로는 커버가 불가능한 부분이 있지 않을까 싶은데 어떻게 생각하시나요?

[kmebin]

서비스의 다른 기능이 필요한 경우는 생각을 못 했네요..!
저도 1번 방식이 좋긴 했지만, 다른 Service에서 사용하는 경우에는 validate 메서드를 public으로 두고, 사용하지 않을 때는 private으로 전환하는 과정이 귀찮기도 했어서 고민이 되네욤 . .

[Shin-Jae-Yoon]

저는 개인적으로 2번은 별로인 것 같고, 1번과 3번이 남는데 이중 1번의 방식을 선호합니다 !

• 3번의 방식도 결국은 MemberRepository를 주입 받아야 한다는 점
• getById 이외에 MemberService에서 필요한 메서드가 생긴다면 MemberService도, MemberRepository도 주입받아야 한다는 점
  • 사실 getById 말고 MemberService의 다른 서비스를 사용하는 경우가 있을 지는 잘 모르겠슴돠
• 검증에 대한 작업이 서비스보다 조금 더 low한 리포지토리까지 내려간다는 점
  • 근데 생각해보면 voucher 미션할 때 repository에 저렇게 넣어놓기는 했었는데.. 괜찮겠다 싶기도 하네여

[kmebin]

MemberService도, MemberRepository도 주입받아야 한다는 점을 간과하긴 했네요.. 😋
검증에 대한 작업이 도메인 영역인 리포지토리에서 진행한다는 점에서 low하다고 볼 수는 없을 것 같습니다..!

[hongdosan]

사실 1번의 방식의 가장 큰 문제점은 순환 구조인데요! 이 문제점은 오히려 장점이 될 수도 있다 생각합니다! 순환 구조가 발생한 것은 그만큼 설계 혹은 로직 구현을 올바르게 하지 못했다는 것이기 때문에, 다시 생각해보게 되는 이점이 있다고 생각합니다! 저도 1번이 좋습니다!

[kmebin]

오케잉! 1번 ㄱ ㄱ