인프런 커뮤니티 질문&답변

abcabc님의 프로필 이미지

작성한 질문수

실전! Querydsl

queryDto, queryRepository라는 네이밍도 관행인가요?

작성

·

401

0

***queryDto, ***queryRepository 라고 네이밍 하던것들 ***AdminDto, ***InstantRepository 처럼 마음대로 바꿔서 사용해도 되나요?

'jpa1활용 1편'에서도 화면에 뿌려주기용 dto같은경우 orderQueryDto라고 네이밍 하시고 '실전! querydsl 사용자 정의 리포지토리'  편에서도 repository내에 custom하게 만든 함수가 핵심비즈니스 로직과 분리할 필요가 있는지 고려해봐야 한다고 말하시면서 memberQueryRepository라는 파일을 새로 만드셨는데 이렇게 핵심비즈니스 로직이 아닌 것들에 대해서 항상 query 라고 붙이시는 이유가 있나요? 이것도 memberRepository의 구현체에 관례적으로 Impl(implementation)을 붙여서 memberRepositoryImpl라고 하는것처럼 관례적인 것인가요?

보통 어드민 페이지같은 화면에 쓰이는 것들을 **queryRepository, **queryDto 로 네이밍 하라는걸로 받아들였는데 query라는 영단어가 너무 뜬금없이 느껴지고 와닿지가 않는것 같습니다. 그래서 이부분을 바꿔서 사용하고 싶은데 관례적으로 쓰이는것인지 아니면 영한님만 그렇게 쓰시는건지 궁금하고 이유가 있다면 이유도 알고싶습니다.

감사합니다~

답변 1

1

김영한님의 프로필 이미지
김영한
지식공유자

안녕하세요. abcabc님

당연히 마음대로 바꾸어 사용해도 됩니다. 단 팀으로 일을 한다면 어느정도 일관성을 갖추는 것은 필요합니다.

예를들어서 회원리포지토리가 있으면

MemberRepository 하나를 사용하는게 가장 응집성이 좋습니다.

그런데 애플리케이션이 너무 커지고 복잡해지면, 핵심 비즈니스 로직과 조회 중심의 로직을 분리하기도 합니다.

여기에서 Command-query separation(CQS)라는 단어가 나옵니다.

핵심 비즈니스 로직은 주로 데이터를 변경하므로 Command

나머지 조회 로직은 Query

이렇게 해서 나눕니다.

그런데 이것은 딱 정해진 패턴이 있는 것도 아니고, 결과적으로 리포지토리를 분리하기 때문에 응집성이 떨어질 수 있습니다.

결국 규모에 따라 적절한 선택이 필요합니다.

감사합니다.

abcabc님의 프로필 이미지

작성한 질문수

질문하기