dto 변환(Web Response 반환)을 어디서 해야 하는가

[ShimFFF]

서비스 계층(Service Layer)과 컨트롤러 계층(Controller Layer)의 역할을 명확히 구분하는 것이 중요함!
그렇다면 두 계층 사이의 데이터 교환 방식은 애플리케이션의 유지보수성, 확장성, 테스트 용이성 등에 큰 영향을 미칠텐데, 우리는 어떻게 접근해야 할까?

Web Response 반환 하는 법 2가지

1. Service가 Response Dto를 Controller에 반환
2. Service가 Entity를 Controller에 반환, Controller가 Dto를 반환

Service가 Response Dto를 Controller에 반환할 때의 관점

장점

• 컨트롤러에서 도메인 로직이 실행되는 치명적인 위험을 예방할 수 있음. (도메인 모델의 일관성 유지에 도움이 됨)

단점

• Dto의 형식이 변할 때 Service 계층까지 변경 영향이 미치는 것은 좋지 않아 보임. (의존성 증가)
• 서비스 계층에서 Dto를 반환하면, 서비스 계층의 단위 테스트에서 Dto를 생성하고 검증하는 코드가 추가되어 테스트가 복잡해짐

Service가 Entity를 Controller에 반환, Controller가 Dto를 반환할 때의 관점

장점

• 서비스 계층은 비즈니스 로직을 처리하고, 컨트롤러는 View와의 상호작용을 처리하므로 각 계층의 책임이 명확히 분리됨
  • 서비스 계층은 비즈니스 로직을 처리하는 책임을 가지고 있는데, view에 종속적인 Response Dto를 반환하는 것은 서비스의 책임이라고 보기 어려움
• Service 간 의존을 한다면 Dto보다는 도메인을 반환하는 것이 좋아 보임. (유연성이 증가)
• Dto 형식이 변경되더라도 서비스 계층은 영향을 받지 않으므로, 서비스 계층의 독립성이 유지됨

단점

• 컨트롤러에 도메인 엔티티가 노출되면, 컨트롤러에서 도메인 로직을 잘못 처리할 위험이 존재함
  • 도메인 모델의 일관성을 해침
• 컨트롤러에서 엔티티를 Dto로 변환하는 추가 작업이 필요하므로, 컨트롤러의 코드의 복잡도가 증가

우리가 고민해야 할 것

• 어떤 방식을 선택하고 그에 따른 트레이드 오프에 대해서
• 새로운 방식이 있다면 설명하고, 이에 대한 트레이드 오프에 대해