repository service

김영한 개발자님 좋은 강의 감사드립니다.

유익한 강의를 따라 스프링 데이터 Jpa를 공부하니 호기심에 이것저것 궁금한게 생기네요. 초보 개발자인 저는 JpaRepository<T, ID>를 활용하면서 설계패턴에 대한 고민을 시작했습니다. 설계패턴을 이론으로 배울때는 별 생각없었는데, 코딩하면서 적용해보니깐 설계하기 애매한게 많더군요. 굉장히 흥미롭고, 그래서 선배 개발자님의 경험이 듣고 싶습니다.

1. JpaRepository는 T에 들어가는 하나의 테이블을 위해서 공통 인터페이스들을 제공해주고 있잖아요. 그렇다면 여러개의 테이블을 위해서는 일일이 JpaRepository를 따로 만들어줘야 할텐데요.

강의에서는 주로 하나의 테이블만을 이용해서 쿼리를 날렸기에, 하나의 JpaRepository로 충분했는데요. 테이블이 한두개면 모르겠는데 테이블 숫자가 많아지면 그에 맞춰 repository 숫자도 계속 늘려줘야 하는건가요?

가령 수백개의 테이블이 있을 경우에도 일일이 repository를 따로 만들어주는 건가요?

2. 테이블당 하나씩 repository를 만든다면, join 쿼리처럼 여러 테이블을 동시에 참조하는 쿼리는 어떤 테이블을 위한 repository에 작성해야할지 모르겠습니다.

예를들어 : '주문자'와 '상품'을 n:n 관계로 잇는 '주문' 테이블을 조회한다고 가정해볼경우. 제가 주문한 상품에 대한 상세정보를 가져오려고 쿼리를 짜면 다음과 같을 것입니다.

select (상품명, 상품가격, 유통기한) from '주문' join '상품' on '주문'.상품id = '상품'.id where '주문'.사용자id = 'qwer1234'

그렇다면 이 쿼리를 '주문자repository'에서 작성해야할지, '상품repository'에서 작성해야할지, '주문repository'에서 작성해야할지 모르겠습니다.

테이블 단위로 repository를 만든다면, 여러 테이블을 넘나들며 query를 날리는 비즈니스 로직이 있을경우, 어떤 테이블을 위한 repository에서 그 쿼리를 작성해줘야 할까요?

join 쿼리만을 위한 repository를 따로 만들어줄까도 생각해봤고, service 측에서 작성해줄까도 생각을 해봤는데요. service 측에서 작성해주는 것은 service랑 repository를 분리하는 것이 퇴색되는 것 같습니다. join을 위한 repository를 따로 만드는 것은 개발하다 구조적인 문제가 생길지 않생길지 몰라서 확신이 안섭니다.

물론 위에 대한 답변들은 프로젝트의 규모나 비즈니스 로직에 따라서 어떻게 분리할지, 통합할지 얘기가 달라지겠지만,

김영한 개발자님은 실무에서 어떻게 균형있게 분리하셨는지 경험을 듣고 싶습니다.

감사합니다.