Repository를 다루는 세 가지 방식

해당 포스트는 인프런의 Java/Spring 테스트를 추가하고 싶은 개발자들의 오답노트 강의의 도움을 받았습니다

Repository를 잘 써야 하는 이유

Repository의 추상화가 잘 될 필요가 있습니다.
다음 세 가지 방식을 비교하면서 살펴봅시다.

첫 번째

Service가 JpaRepository를 직접 의존하는 방식입니다.

사실 이렇게 해도 됩니다!
JpaRepository 자체가 인터페이스이기 때문에 테스트할 때는 FakeRepository가 JpaRepository를 implementes 하면 되기 때문입니다.

하지만 이런 경우 단점이 있습니다.

1. Fake가 불필요한 Jpa의 인터페이스를 구현해야 합니다.
2. Service가 불필요한 모든 메서드를 알게 됩니다.
3. Domain Entity가 Persistence Entity에 종속됩니다. (도메인 엔티티와 영속성 객체를 분리할 수 없습니다.)
4. Service가 Jpa에 의존적입니다.

두 번째

Repository 인터페이스를 하나 더 만드는 방식입니다.
의존성 역전입니다.

이렇게 하면 Service는 JpaRepository의 메서드를 모두 알고 있지 않아도 되므로 첫 번째 방식에서 2번은 해결이 되었습니다.

그러나 여전히

1. Domain Entity가 Persistence Entity에 종속됩니다.
2. Service가 Jpa에 의존적입니다.

세 번째

개선된 아키텍처에 적용된 방식입니다.

첫 번째, 두 번째 방식에서의 문제점이 모두 해결이 됩니다.

서비스는 추상화 되어야 하는가?

강의에서는 서비스까지는 추상화되지 않아도 좋다는 관점을 가지고 있습니다.

1. 서비스 자체가 유즈케이스여야하기 때문에
2. 컨트롤러는 테스트가 굳이 필요한 영역이 아니기 때문에

위와 같은 이유 때문이었습니다.

결론

결국 우리가 정말 집중해야 하는 것은 도메인입니다.
기술은 알고나면 당연한 게 많습니다.
기술력이 떨어져도 비즈니스가 좋으면 성공할 수 있습니다.

그런데 우리는 항상 개발할 때

• 데이터베이스는 Oracle을 쓸지 MySQL을 쓸지 MongoDB를 쓸지
• 웹서버는 Nginx를 쓸지 Apache를 쓸지
• REST인지 GraphQL인지
• Spring인지 Node.js인지

고민하고 있습니다.

도메인이 먼저 개발되어야 합니다.

비즈니스에 집중하는 DDD를 실천합시다.