37. 트레이드 오프, SpringDataJPA 사용에 따른 구조변화

우리가 과거 SpringDataJPA를 썼을 때의 구조를 보자.

 

뭔가 우리가 의도했던 repository가 SpringDataJpaRepository와 어댑터 역할을 하는 꼴이 되었다.

 

그리고, 한눈에 보기에도 좀 복잡해 보인다.

뭐 이렇게 보면 낫긴하다. 

 

여튼간에, 유지보수에도 비용이 든다.

 

예를 들어 서비스가 추상화에 의존하지 않고 바로 저 SpringDataRepository구현체를 의존한다고 생각해보자.

 

이게, 우리가 객체지향 SOLID 하면서 추상화에 의존하는게 좋다고 하긴 했지만,

어떤 게 나은지 진짜 곰곰히 생각해 봐야 한다.

 

만약 위처럼 우리가 의도한 리포지토리가 SpringDataJpaItemRepository의 어댑터 역할을 한다고 했을 때,

유지보수할 때

Service에서는 뭘 의존하지? 아 ItemRepository를 의존하는 구나. 그럼 구현체를 뭘로 했지? 아, 이걸로 했구나.

이거는 어떤 식으로 동작하지? 아, 결국 SpringDataJpaItemRepository를 사용해 동작하는 구나.

이렇게 거치는 게 많게 된다.

근데 딱 ItemService가 직접적으로 구현체 SpringDataJpaItemRepository를 의존하게 되면,

Service는 SpringDataJpaItemRepository를 의존하며 사용하는 구나.

딱 알게 된다.

 

이게 객체지향 SOLID 하긴 하지만, 

정말 그 상황에 딱 맞는 구조가 좋다.

 

예를 들어 일회성 프로젝트는 굳이 인터페이스로 만들 필요는 없고, 그냥 곧이 곧대로 구현체에 의존하도록 해도 괜찮을 것 같다.

또, DB가 바뀔 경우가 얼마나 있을 것 같나.

 

이런 아키텍쳐 부분은 정말 경험과 고민, 예상, 생각이 많이 든다.

 

 

소프트웨어 공학에서 You Ain't Gonna Need It, YAGNI라는 원칙이 있는데, 말 그대로 필요한 경우에만 기능을 추가하라는 것이다.

개발하다 보면 확장성을 위해서 미리 작업하는 경우가 있는데, 이런 작업을 미리 하지 말라는 뜻이다.

 

 

영한 선생님도

일단 간단하게 빠르게 개발을 하고

그 후 프로젝트가 커지면 이후에 리팩토링 해서 그 부분들을 정리하는 게 나은 선택인 것 같다고 한다.

 

 

하지만 나는 좀더 다른 아키텍쳐가 될 수 있을 것 같다.

나는 한발자국 더, 생각할 수 있을 것 같다.

 

 

트레이드 오프 하면 보통 교환 이라는 느낌인데,

말 그대로 어느 하나를 선택하면 여러 성과 중 어떤 쪽의 성과가 줄어든 다는 뜻이다.

 

뭐 위 같은 경우는 

DI, OCP를 지키기 위해 기존처럼 ItemRepository를 어댑터로써 쓰냐

어댑터를 제거하고 구조를 단순하게 하지만 DI, OCP를 포기하느냐.