여태까지 JdbcTemplate, MyBatis, JPA 를 배우면서 최대한 서비스 로직은 안건들고 Data접근기술만 갈아끼우기 위해 아래와 같이 ItemService는 ItemRepository 인터페이스에만 의존하게끔하고 데이터 기술별로 구현체를 만들어서 갈아끼우는 형식을 구현했었다!

이 방법이 유지보수적인 관점에서는 중간에 어댑터(JpaItemRepositoryV2)가 들어가면서 DI, OCP원칙도 잘 지키고 ItemService를 고치지 않고도 ItemRepository 구현체를 변경할 수 있다는 확실한 구조적인 장점이 있다!

하지만 반대로 구조가 복잡해지면서 어댑터 코드와 실제 코드까지 함께 유지보수 해야 하는 어려움도 발생한다

여기서 아래와 같은 선택도 가능할 것이다! ItemService의 Repository의존성 관련 코드를 일부만 고쳐서 직접 Spring Data JPA 코드를 사용하게끔 할수도 있을 것이다! DI, OCP 원칙을 포기하고 구조를 단순하게 가져갈 수 있다는 장점이 있다!

이게 바로 Trade Off다! 즉 정답은 없는 것이다! 여기서는 구조의 안정성 vs 단순한 구조와 개발의 편리성 사이의 선택이다

개발을 할 때는 항상 자원이 무한한 것이 아니다. 그리고 어설픈 추상화는 오히려 독이 되는 경우도 많다. 여기서 말하는 비용은 유지보수 관점에서 비용을 뜻한다. 이 추상화 비용을 넘어설 만큼 효과가 있을 때 추상화를 도입하는 것이 실용적이다.

실질적으로 간단한 플젝에서 Spring Data JPA의 RDB기반에서 MongoDB로 바꿀 순간이 얼마나 있을까?! 모든 DB접근 로직을 구조를 최대한 지키려고 클래스를 많이 생성하며 구조를 칼같이 지켰는데, 결국 DB를 바꾸지 않는다면 헛수고가 되는 것이다!

프로젝트 상황에 맞는 선택을 하는 개발자가 좋은 개발자다!

그리고 보통 아래와 같은 구조를 많이 사용한다! 기본적인 CRUD는 Spring Data JPA로, 동적쿼리는 QueryDsl로!