위에 있는 request response가 지금 내가 프로젝트에서 구현하고 있는 코드다.
이렇게 만든 이유는 controller에 많은 부하를 주지 않기 위해서라는 생각 때문이었다
그러다 오늘 테스트 코드를 작성하면서 service에서 dto -> entity 변환, entity -> dto 변환까지 다 하면 이건 역할이 너무 많은 것이 아닌가? 라는 생각을 하게 되었다.
일단 내가 만든 코드는 계층간의 분리가 전혀 되어 있지 않은 코드다.
요청으로 들어온 데이터가 바로 서비스단 까지 흘러 들어가게 설계가 되어 있다.
문제점
- 메서드의 재사용성이 떨어짐
- 특정 DTO를 이용해야 되기 때문에 재사용성이 떨어지게 된다.
- 계층간 의존성 강결합
- 서비스 계층에서 Controller 계층에 강하게 결합되어있다는 문제가 있다.
내가 고민하는 것
- Entity를 만드는게 전부인 그런 로직에서 Entity또한 외부에서 만들어진다면 해당 로직이 필요한 것인가?
- Entity가 Controller 계층 까지 올라가게 되는데 이것 또한 계층이 분리가 되어 있지 않은 것 같다?
- OSIV를 사용하고 싶다.
여기까지가 내가 고민하는 것들이다.
그 중 3번을 강하게 사용하고 싶다.
이유는 추 후 확장성을 위한 것인데 OSIV를 사용해서 여러 요청이 동시에 몰리더라도 커넥션풀이 마르지 않게 하기 위한 것을 적용하고 싶었다. 그렇기 떄문에 service계층에서 dto로의 변환 과정까지 처리하고자 했다.
그렇다면 내가 지금 구현한 코드가 정확한 코드인가?
NO!! 내 생각에는 아닌 것 같다.
그림 하단의 request, response
저렇게 중간에 mapper를 이용해서 변환을 처리해주고 있다.
이는 뭔가 dto로 변환하는 번거로운 과정이 하나 더 추가 되게 되지만 이렇게 사용할 경우 코드의 엔티티의 재활용이 가능하게 된다.
또한 내부에서만 사용되는 dto를 사용하게 된다면 메서드 재활용 측면에서도 도움이 되지 않을까 하는 생각이 든다.
그럼 바로 적용하면 되지 뭐가 문제인가?
변환 과정이 너무 많다 일단 변환 과정이 너무 많아진다는 문제점이 있다.
하지만 적어도 지금의 계층간 의존성이 강한 코드보다는 조금 더 좋을 것 같다는 생각이 든다.