작성
·
980
8
안녕하세요.
이전부터 말씀해주신 CQRS에 관해서 간단한 질문이 있습니다.
예를 들어 Member엔티티에 관해 아래처럼 2개의 레포지토리로 쪼갠다고 가정할게요.
- MemberQueryRepository(읽기)
- MemberCommandRepository(쓰기)
저희가 JPA Data의 이점을 살리려면 JpaRepository를 상속받아서 사용한다고 강의에서 배웠는데요.
읽기 관련 쿼리가 들어있는 Query와 쓰기 관련 쿼리가 들어있는 Command 2개의 레포 모두 JpaRepository를 상속받아서 사용하나요?
JpaRepository에는 단순 find~로 시작하는 읽기 메소드뿐만 아니라 delete, save등 쓰기에 관한 메소드도 같이 들어가있어서 읽기/쓰기 레포에서 모두 상속받아서 사용한다면 나중에 작업을 할 때 단순 조회/저장/삭제 등을 어떤 레포에서 사용해야할 지 혼란이 올 것 같습니다.
CQRS에 대해서는 이론만 알고있었지 실제로 적용해본적이 없어서 많이 혼란스럽네요.
감사합니다 :)
답변 3
5
안녕하세요. teamhide님
여러가지 방안이 있겠지만, 제가 추천하는 방법은 MemberRepository를 하나 만드시고, 여기서는 JpaRepository를 상속 받은 기본적인 CRUD (단순한 읽기 포함)를 제공합니다.
이 MemberRepository의 역할은 엔티티를 주로 조회하는 기능들을 제공하고 단순합니다. 대부분 핵심 비즈니스 로직에서 사용됩니다.
매우 복잡한 쿼리와 DTO들을 조회하는 부분은 전용 조회 리포지토리로 만들고 MemberQueryRepository로 분리하면 좋습니다. 이 경우 JpaRepository를 상속 받지 않고 그냥 스프링 빈으로 만드셔도 됩니다.
실무에서 이런 부분은 주로 Querydsl을 사용하게 됩니다.
감사합니다.
1
0
하나만 더 질문드릴게요.
실무에서는 파이썬을 사용하고 있지만 스프링 구조처럼 Service, Repository까지 나눠둔 Layered architecture를 채택하여 사용하고 있는데요.
복잡한 읽기 쿼리의 경우 추상화하여 재사용성을 높이기가 쉽지 않더라구요.
그래서 하나의 레포지토리 메소드가 하나의 서비스에서만 사용되는 경우도 심심치않게 발생하는 것 같습니다. (하나의 쿼리가 하나의 뷰에서만 사용된다고 말씀드리는게 나을수도 있겠네요)
그동안 재사용성을 높이기위해 많은 노력을 해봤지만..서비스 요구사항에 따라 어쩔 수 없는 부분인 것 같기도 합니다.
요약하자면, 읽기 레포지토리에 있는 하나의 메소드가 단 한군데에서만 쓰이는 경우들이 많이 발생하는 것 같은데 이 부분은 피할 수 없는 부분일지 영한님의 생각을 듣고 싶습니다.
네 화면에 맞춤으로 제공되는 복잡한 전용 쿼리 들이 있습니다.
쿼리 자체가 화면에 맞추어져서 제공되기 때문에 재사용이 쉽지 않습니다.
오히려 이런 부분은 재사용이 어렵다고 인정하고 분리하는 것도 방안입니다.
감사합니다.