Repository에서 CQS를 포기하고 수정한 과정

1. 문제상황

Repository단에서 Command와 Query를 분리하여 책임을 분리함으로써 코드 응집도와 유지보수성을 높이고자 하였다.

이에 처음 시도했던 방법은 아래와 같다.

 Create, Update, Delete를 담당할 CommandableRepo Interface와 Read를 담당할 QueryableRepo Interface로 나누었다.
구현체는 CommandRepo, QueryRepo로 구현한다.

하지만, 문제가 생겼다.

어떠한 엔티티를 save해야 하는 상황을 가정할 때, 중복조회나 다른 조회 메서드를 이용해야 하는 상황이 주로 발생했다.

이럴때, Repository를 사용해야 하는 Service 계층에서 의존성이 너무나 많아지는 문제가 발생했다.

2. 문제해결 과정 1 - interface 다중상속

JpaRepository를 상속받는 Consultation를 생성하고 CommandableRepo와 QueryableRepo를 다중상속 시켜서 하나로 묶어보았다.

그리고 이 Repository를 CRD가 필요한 서비스에서 이 하나의 Repository만 참조하여 의존성을 줄여보자고 생각했다.

나름대로, 규칙을 만들었었다.

1. Command와 Query 둘 다 필요한 서비스에서는 JpaRepository, CommandableRepo, QueryableRepo를 다중상속한 Repository를 참조하도록 한다.

2. Read만 필요한 서비스에서는 CommandableRepo만 참조하도록 한다.

 

하지만, 이런식으로 하면 "CQS의 의미가 없지 않나?" 라고 심각하게 고민하였고 또한 내가 담당한 서비스의 경우 Update 쿼리를 짜는경우가 많지 않기에 사실 CommandableRepo의 존재가 불확실했다.

따라서 다른 해결 방안을 찾아보았다.

3. 문제해결 과정 2 - CommandableRepo 삭제

CQS라는 개념은 생각하지 않기로 했다.

보통 조회하는 쿼리를 많이 작성해야했고, QueryableRepo는 살리는게 응집도나 유지보수성에서 훨씬 좋다고 생각했다.

그리고 보통 내 서비스의 경우 JPA의 dirty checking 기능을 이용하여 update를 하였기에, save나 delete이외의 쿼리를 작성하는 일이 별로 없었다. 따라서 CommandableRepo는 과감하게 삭제하였다.

1. QueryableRepo repository는 복잡한 조회의 책임

2. JpaRepository와 QueryableRepo 를 다중상속한 repository는 save, delete, 복잡한 조회까지 모두 책임

위 두가지로 분류하기로 정했다.

해당방식을 사용하는게 의존성을 줄일 수 있고, 충분히 책임을 분리할 수 있는 방법이라고 생각한다.

4. 회고

CQS 패턴만 생각하다보니 내가 개발하고 있는 서비스의 특성은 제대로 생각하지 않은것 같다.

update 쿼리가 많고 배치처리를 해야하는 상황이 많아서 직접 해당 쿼리를 짜야하는 상황이라면 CQS패턴을 적용해볼만 하다고 생각한다. 또한 조회용 DB와 쓰기용 DB가 분리되어있는 상황에서도 적용해볼 수 있을 것 같다.

사실 의존성 문제를 구현전에 생각하지 못한 것은 아니다. 하지만 실제로 구현해보니 의존성은 점점 늘어만 났고 추후에 더 큰 문제가 될 것 같아 다른 방법으로 해결하고자 했다.

문제를 미리 예측하는 것도 중요한 부분이라고 생각하지만 실패에 대한 경험도 중요하다고 생각하기에 기록한다.