인프런 커뮤니티 질문&답변
작성한 질문수
Service dto를 만드는 대신 도메인 객체를 생성하는 전략은 별로인가요?
작성
·
107
답변 2
0
안녕하세요, 박정선 님!
아주 간단한 시스템이라면 그래도 무방하겠지만, 권장하지는 않습니다.
Presentation Layer가 도메인 객체를 직접적으로 알게 되는 경우, 도메인에 변경이 생기면 Presentation Layer 도 영향을 받게 됩니다.
Presentation Layer가 도메인 객체를 알고 있다 보니, 도메인 객체의 메서드를 호출하는 등 여러 조작도 가능해 원하지 않는 동작이 발생할 수도 있습니다.
다소 간단한 예제 프로젝트와는 달리, 도메인으로 변환하는 과정에는 보통 많은 이해관계가 얽혀 있습니다. 단순히 외부에서 받은 데이터 뿐만 아니라, 다른 시스템의 데이터를 가져오거나, 복잡한 정책에 따른 내부 연산 과정을 거쳐 도메인이 생성되기도 하는데요. 이런 이유로 Controller에서 바로 도메인을 생성하게 되면, 이미 만들어진 도메인 객체에 불필요하게 update하는 구조가 많이 생겨날 수 있습니다.
도움이 되셨기를 바랍니다.
감사합니다. 🙂
0
안녕하세요, 인프런 AI 인턴입니다. 박정선님 질문 감사합니다.
서비스 계층에 DTO(Data Transfer Object)를 사용하는 이유 중 하나는 각 계층 간의 의존성을 줄이고 역할을 명확히 하는 데 있습니다. Controller에서 직접 도메인 객체를 사용하는 방법은 간편해 보일 수 있지만, 이는 몇 가지 단점을 가질 수 있습니다.
유지 보수성: 특정 로직이 변경되었을 경우, Presentation Layer와 Domain Layer 모두 수정이 필요하게 되어 수정의 영향 범위가 커집니다.
캡슐화 및 역할 분리: 각 계층은 자신의 역할과 책임이 명확해야 하며, DTO는 이러한 계층 간의 데이터 전송을 담당합니다. Controller가 도메인 객체에 직접 접근하면 Presentation Layer가 불필요한 비즈니스 로직을 알게 될 수 있습니다.
확장성 및 변경 용이성: 비즈니스 로직이나 데이터 표현이 변경될 경우, 중간 계층에서의 변경이 용이하며 다른 레이어에 주는 영향을 최소화할 수 있습니다.
그러므로 일반적인 설계 원칙에서는 Presentation Layer에서 Service Layer로의 데이터 전송 시 중간에 Service Layer용 DTO를 사용하는 것이 권장됩니다. 다만, 프로젝트의 규모와 복잡도에 따라 이러한 구조를 단순화할 수도 있습니다. 프로젝트의 요구사항과 팀의 개발 속도, 그리고 생산성을 고려해 구조를 결정하는 것이 중요합니다.
기존에 유사한 질문과 답변을 찾았는데, 비슷한 맥락에서 controller, service용 dto를 분리시키는 것에 대한 질문을 참고해 보시면 도움이 될 것입니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
아 그렇군요.. 지금까지 도메인이 다른 쪽에 의존하지않는 구조만 생각했는데 역으로 생각해볼 필요도 있는 것 같네요.
궁금한 것이 하나 더 있는데요. 일반적으로 다른 헥사고날 예제 코드를 보면 Domain class의 내부에서 dto를 매개변수로 받아 도메인 객체로 변환하는 메서드를 가지고 있는 것을 봤습니다.(from / to / of 와 같은 이름으로요) 저는 이런 경우 불필요하게 도메인이 외부 dto에 의존하는 것 같아서 약간 꺼려지더라구요... 강사님의 코드를 보면 dto class 내부에서 도메인으로 변환하는 메서드를 만든 것을 확인할 수 있는데요, 혹시 이런 구조가 도메인이 dto에 의존하지않도록 만들기위해서 그렇게 구현하신 것일까요???