dto의 layer에대해 질문 드립니다.

안녕하세요. 김창현님 좋은 질문입니다^^

이상적으로는 서비스 계층에서 엔티티를 바로 받는 것이 좋은 선택이라 생각합니다. 그러면 서비스 계층은 엔티티에만 의존하기 때문에 서비스 계층의 재사용성이 높아집니다.

하지만 현실적으로 엔티티만 가지고 서비스 계층의 비즈니스 로직을 다 동작시키기는 어려운 경우가 많습니다. 서비스 계층을 실행하기 위해서는 상당히 많은 부가정보들이 추가되기 때문이지요.

그리고 주문 데이터 같은 경우는 매우 복잡한 엔티티를 만들어야 하는데, 이것 자체가 핵심 비즈니스 로직일 확율이 매우 높습니다. 그런데 핵심 비즈니스 로직을 외부에서 생성하는 것이 좀 애매하기는 하지요.

이런 점들 때문에, 딱 한가지 경우의 수를 가지고 간다기 보다는, 한 프로젝트 안에서도 상황에 맞는 선택이 필요합니다.

====== 여기서부터는 제가 질문을 잘못 이해해서, 반대로 엔티티를 조회하는 경우를 생각했습니다. ㅎㅎ =====

사실 이 부분은 딱 정해진 답이 없습니다.

(하지만 이렇게만 말하고 답변을 끝내기에는 너무 재미있는 주제이지요 ㅎㅎ)

특정 컨트롤러에서만 사용하는 DTO는 해당 컨트롤러에서 처리하는 것이 맞겠지요.

그런데 이 DTO를 여러 컨트롤러에서 재사용해야 하는 상황이라면 조회 전용 서비스 클래스를 만들고 여러 컨트롤러에서 해당 조회 전용 서비스 서비스 클래스를 호출하는 것이 더 좋은 선택입니다.

그리고 강의 뒷쪽에서 설명드리지만, OSIV, 리포지토리에서 DTO 직접 조회, 복잡한 상황 등등 다양한 변수가 많습니다^^

이런 부분들을 고려해서, 같은 프로젝트라 하더라도 해당 상황에 맞는 적절한 선택지를 가져가는 것이 좋다 생각합니다.

그런데 질문에 답이 있다고 사실 질문하신 내용중에 '다양한 경로에서 모일 수 있는 request dto들을 전부 다 Service레이어에서 처리하는 것 보다는'이라는 말씀을 해주셨는데요. 애플리케이션 설계에서 사실 이 부분이 잘 해결하는 것이 정말 중요합니다. 안그러면 뚱뚱한 슈퍼 Service 클래스가 탄생하거든요.

서비스 레이어도 핵심 비즈니스 로직을 가지고 있는 서비스 로직과, 화면에 맞춘 읽기 전용 서비스 로직을 별도로 분리해서 설계하면 이런 문제를 어느정도 완화할 수 있습니다^^

도움이 되셨길 바래요^^

아침에 일어나자마자 답변 달렸나 확인해봤는데 역시나.. 👍

친절한 답변 감사합니다. 

답변해주신 내용으로 좀 더 고민해봐야겠습니다 :)