-
질문 & 답변
카테고리
-
세부 분야
백엔드
-
해결 여부
미해결
DTO 클래스의 위치에 대해 질문있습니다!
23.11.09 15:05 작성 조회수 275
1
- 학습 관련 질문을 남겨주세요. 상세히 작성하면 더 좋아요!
- 먼저 유사한 질문이 있었는지 검색해보세요.
- 서로 예의를 지키며 존중하는 문화를 만들어가요.
- 잠깐! 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요.
안녕하세요! 좋은 강의 감사드립니다 ㅎㅎ
(강의에서 나온대로 패키지와 클래스를 구성한 상태입니다.)
혹시 DTO를 framework 패키지에 넣는 이유가 있을까요?
저는 개인적으로 UseCase나 InputPort에 framework 패키지에 대한 import가 생기기 때문에 의존성이 생긴다고 판단해 application에 DTO를 생성할 것 같습니다.
혹시 제가 생각하지 못한 다른 이유가 있는지 궁금합니다!
답변을 작성해보세요.
3
han jeong heon
지식공유자2023.11.09
네 안녕하세요. 우선 예리한 지적 감사합니다. ^ ^
움 저도 고민을 했었는데요. 우선 DTO는 외부와 상호작용하는 세부내역을 담고 있는 데이터 전송 객체의 의미이기 때문에 프레임워크 헥사곤에 위치해야 하고 API를 발행하는 컨트롤러 클래스에서 입출력값으로 사용됩니다. 문제는 이것이 그대로 애플리케이션 헥사곤의 유스케이스 입출력 값으로 사용된다는 점에 있습니다.
따라서 애플리케이션 헥사곤에 사용되는 DTO가 애플리케이션 헥사곤에 위치해야 된다는 의견은 일리가 있는 말씀이신데요.
그런데 사실 이런 고민이 있었습니다. 헥사고널 아키텍처를 엄격하게 적용하려면 프레임워크 헥사곤에서 사용한 DTO를 별도의 객체로 매핑해서 어플리케이션에 전송해야 합니다. 아래 문서를 참고 하면 DTO를 어플리케이션 헥사곤에 필요에 적절한 Commands and Queries 객체로 변경하고 있습니다. 따라서 Commands and Queries는 유스케이스 목적에 맞게 책임을 가지고 정의가 되어야 겠죠.
https://github.com/Sairyss/domain-driven-hexagon
그런데 샘플 도메인 주제가 단순하다 보니 그렇게 엄격하게 적용하면 딱히 DTO와 Commands and Queries 정의가 구별이 될 것 같지도 않고 오히려 과도한 Boiler Plate가 생겨나고 강조하고 싶은 도메인 헥사곤 보다 작업 분량이 많아 지겠더라고요. 그래서 별도 어플리케이션 객체를 매핑하지 않고 DTO를 바로 사용했습니다.이런 부분도 어느정도 타협 및 트레이드 오프가 필요한 사항 같습니다. 감안해 주시면 감사하겠습니다. ^ ^;;;
답변 1