Couchbase Spring data repository 적용기(3)

티몬이 CouchbaseTemplate으로 직접 질의하던 로직을 Spring Data Repository로 옮긴 연재의 마지막 3부다. Repository에 사용자 정의 기능을 끼워 넣어 Couchbase의 증분값 호출을 간편하게 만드는 방법과 그때 지켜야 할 이름 규칙을 다룬다. 마지막에 도입 후의 장점과 아쉬운 점을 정리한다.

핵심 포인트

Spring Data는 객체 매핑을 추상화해 저장소마다 접근 계층을 직접 구현하지 않아도 되게 해준다.
Couchbase의 counter는 오라클 시퀀스 같은 자동 증가 기능을 한다.
기존에는 템플릿에서 버킷을 직접 꺼내 counter를 호출하고 있었다.
사용자 정의 인터페이스와 구현 클래스를 만들어 도메인 Repository가 상속하면 그 메서드를 그대로 쓸 수 있다.
구현 클래스 이름은 반드시 Repository 이름 뒤에 Impl을 붙여야 자동 탐색에 걸린다.
접미사를 바꾸고 싶으면 설정으로 지정할 수 있다.

상세 정리

연재 구성: 1부는 기본 CRUD를 Repository 상속으로 대체하는 내용, 2부는 직접 만들던 뷰 질의를 메서드로 옮기는 내용, 3부가 증분값 호출이다.
기존 방식: 영수증 저장소의 카운터 조회 메서드가 CouchbaseTemplate에서 버킷을 얻어 counter를 부르는 형태였다.
옮기려는 이유: 같은 동작을 Spring Data Repository 위에서 쓰고 싶었다.
확장 지점: Spring Data는 사용자가 직접 구현한 기능을 Repository에 추가할 수 있게 지원한다.
구현 1 인터페이스: 카운터를 반환하는 메서드 하나를 가진 인터페이스를 따로 정의한다.
구현 2 클래스: 그 인터페이스를 구현하며 CouchbaseTemplate을 주입받아 버킷의 counter를 호출하고 값을 꺼내 반환한다.
구현 3 상속: 도메인 Repository가 기본 Repository와 함께 그 사용자 정의 인터페이스를 함께 상속한다.
사용: 이후에는 Repository에서 카운터 메서드를 바로 호출해 증분값을 얻을 수 있다.
검증: 카운터를 두 번 연속 호출해 나중 값이 더 큰지 확인하는 테스트를 붙였다.
이름 규칙: 구현 클래스는 도메인 Repository 이름에 Impl을 붙인 형태여야 한다.
규칙의 이유: 네임스페이스 설정을 쓰면 지정한 패키지 아래를 자동으로 훑어 사용자 기능 구현체를 찾는데, 그 탐색이 접미사를 기준으로 하기 때문이다.
대안: 다른 접미사를 쓰고 싶으면 별도 설정 값으로 바꿀 수 있다.
도입의 장점 1: Repository 인터페이스에 메서드만 정의하면 되는 간편함이 있다.
도입의 장점 2: 메서드 이름만으로 어떤 질의인지 유추할 수 있어 가독성이 좋다.
아쉬운 점 1: Repository를 충분히 활용하려면 design document 이름과 엔티티, 뷰의 관계를 초기 설계 단계부터 고려해야 한다.
아쉬운 점 2: Stale 옵션처럼 뷰 질의를 세세하게 제어할 수 없다.