DTO 침투 레이어 어디까지?

[Libienz]

1. Controller
2. Controller - Service
3. Controller - Service - Repository

[Libienz]

리비 발제 의도

• 팀 프로젝트에서 팀원들과 DTO 침투 레이어 관련해서 얘기할 때 의견이 쉽게 통일 되어서 많은 얘기를 해보지 못함
• 나와 다른 의견을 가진 사람의 얘기를 듣고 시각을 넓혀 보고 싶어서 발제했다.

콜리 의견: DTO 침투 레이어를 서비스까지

• 하나 이상의 도메인과 그에 맞닿는 서비스를 다루게 될 경우에 컨트롤러 코드가 오염되는 경우를 경험함
• 컨트롤러가 너무 많은 것을(호출 순서, 도메인 구성) 아는 것이 좋지 않다고 생각

에버 의견: DTO 침투 레이어를 컨트롤러까지

• 레이어를 엄격히 분리했을 때의 장점이 있다고 생각.
• 엄격히 분리하면 컨트롤러가 받는 RequestDto와 서비스로 넘겨주는 RequestDto까지 서로 나눌 수 있을 것 같은데 이와 같은 설계까지도 어색하지 않다는 생각을 가지고 있다.
• 서비스 로직이 재사용 가능해야 객체지향적인 설계가 되기 때문

제리 주장: DTO 침투 레이어를 서비스까지

• 설계의 근본적인 의존 방향을 생각하면 DTO를 확실하게 끊어내는 것이 맞다. (서비스는 도메인만 알도록)
• 다만 도메인이 복잡해질수록 DTO로의 매핑과정은 무시못할 정도로 복잡해진다.
• 많아진 클래스 파일, 의미 없는 단순 매핑등을 컨트롤러가 담당해야 하는데 설계의 단순성과 개발 인력 리소스 문제를 봐서라도 DTO 침투 레이어를 서비스까지 설정하는 것이 좋다고 본다.

리비 주장: DTO 침투 레이어를 컨트롤러까지

• 서비스 메서드가 DTO를 알게되는 순간부터 서비스 메서드는 특정 핸들러 메서드와 강결합이 생김
• 서비스 클래스의 재사용성을 고려하면 컨트롤러에서 DTO 맥락을 끊는게 맞다.
• DTO는 뷰와 굉장히 밀접한 관련이 있는데 이를 고려했을 때도 서비스가 뷰를 안다는 것은 어색해보임

제리: 서비스 로직의 재사용성을 경험해본 사례가 있는가?

제리의 발언 - DTO 침투 레이어를 컨트롤러까지로 구분해야 한다는 의견에서 서비스 로직의 재사용성 이야기가 나왔었음. 다만 findById등의 간단한 메서드이외에 재사용 맥락이 있는 서비스 메서드를 본적이 있는지 궁금함

• 에버, 리비: 음슴.. 하지만 그럴 가능성이 있다고 이야기할 수 있음
• 콜리: DTO를 컨트롤러단에서 제한함으로써 컨트롤러 책임이 높아지고 캡슐화가 깨지는 듯한 불이익들이 있다. 재사용성을 강조했는데 일어나지도 않은 미래의 확장성을 위해서 생산성 등의 더 중요한 가치를 놓치고 있는 것은 아닌가?
• 리비: findById등 간단한 서비스 메서드는 분명히 재사용되고 도메인 반환을 필요로 함. 만약 특정 패턴을 적용하지 않고 DTO를 서비스 클래스까지 내린다면 해당 서비스 클래스의 메서드를 어떤 것은 도메인을 반환하고 어떤 것은 DTO를 반환하고 있을 것임. 이러한 구현은 서비스 클래스의 책임을 희석시키는 굉장히 좋지 않은 설계라고 생각. (뷰를 바라보는지 도메인을 바라보는지 경계가 모호). 즉 서비스 클래스 메서드의 재사용성을 인정하고 생산성을 양보하는 쪽이 좋아보인다.

컨트롤러로 DTO handling을 한정 했을 때 코드 생산성이 그렇게까지 낮아지나?

리비의 발언 - 지금 이야기하고 있는 주제는 DTO 변환로직을 어디 위치시키느냐의 문제라고 생각함. DTO변환 로직이 서비스에서 컨트롤러로 옮겨간다는 액션 하나로 코드가 그렇게 더러워질일이 없을 것 같음

• 에버: 컨트롤러로 DTO 범위를 제한했을 때 캡슐화가 깨진다고 말했었는데 사례를 공유해주면 좋을 것 같음
• 콜리: 미팅�과 미팅에 참여한 메이트들의 리스트를 하나의 DTO로 반환해야 하는 경우가 있었음. 그 때 당시에 DTO 활동 범위를 Controller로 제한했었음. 이 때 컨트롤러에서는 미팅 관련한 기능 호출을 위해 MeetingService를 알아야 했음. 얻어온 미팅을 통해 컨트롤러는 다시 또다른 서비스에 관련된 메이트를 요청해야 했다. 즉, 컨트롤러가 하나의 요청에 대한 작업 순서를 알고 있는 어색한 상황이 발생했고, 두개의 도메인을 합치는 과정에서 컨트롤러 코드가 비대해지는 단점 또한 파악할 수 있었다. 해당 상황은 서비스까지 DTO를 내리도록 허용하면 해결할 수 있는 문제였다. 실제로 해결했고.
• 리비: 사실 미팅과 메이트를 통합하는 새로운 도메인을 구현하거나 상위 서비스 개념을 사용하면 되었을 것 같음. 서비스까지 DTO를 내리는것이 유일한 해결책은 아니라고 생각

프록시 객체에 대한 제어를 컨트롤러에서 하는 것에 대해 어떻게 생각하는지?

제리의 발언 - 컨트롤러에서 변환을 하게 되면은 프록시 객체에 대한 변환은 컨트롤러에서 담당하게 된다. osiv와 관련된 LazyInitializationException 감당 가능?

• 리비: 감당 불가능 하긴함. 근데 당신들 트래픽 그렇게 많음 ㅋ? 넝담이고 잘 몰라서 막연하게 대답할 수 밖에 없는데 필요한 필드를 터치하는 등 다양한 해결책이 있을 것이라고 생각함

다들 생각이 바뀌었는지?

• 리비: 서비스는 뷰 로직을 알아서는 안된다고 아직까지 생각. 이번 프로젝트에서 서비스 메서드들이 재사용되는 맥락도 경험했어서 생각이 바뀌진 않았다.
• 콜리: 실무랑 프로젝트가 어떤지 잘 모르는 입장에서 과한 확장성을 고려하고 싶지 않음. 아직까진 서비스에서 DTO 반환하는 것이 핏하게 떨어지는 부분이 있다고 생각한다. 생각이 바뀌지 않음.
• 에버: DTO는 사용되는 맥락이 분리되면 될 수록 좋다고 아직까지 생각. 다음에는 서비스 메서드가 재사용되는 사례를 좀 더 자세히 설명할 수 있도록 준비해야겠음. 리소스가 많이 들어서 트레이드 오프가 있을 뿐이지 어쨋든 좋은 건 맞다고 생각. 생각이 바뀌지 않음.
• 제리: 프로젝트 별로 유연하게 결정할 것 같고 절대적인 기준은 없다.