목록 조회에서 개념(도메인)객체를 반환할 때

제미니의 개발실무 - 커머스 백엔드 기본편

해결된 질문

작성

현재 코드상으로 목록조회에서도 개념객체를 활용하는 것으로 확인했습니다!

하지만 한 개념 객체가 여러 개념 객체를 포함하는 경우가 있는 상태에서 페이지네이션 같이 모든 개념객체의 필드를 채워줄 필요가 없는 경우도 있을 거 같습니다. 이때,

필요한 컬럼만 추출한 데이터를 담는 별도 dto용 객체를 만든다
개념 객체의 일부를 채운 값을 Page에 반환한다

실무에선 둘 중 어느 방식을 적용하는지 궁금합니다!

제 생각에는 개념(도메인) 객체는 항상 완전한 상태로 있어야 하므로 별도 프로젝션 dto용 객체를 만들어서 서비스단에서는 도메인 객체가 아닌 해당 dto 객체를 내려주는 것이 낫지 않을까 생각합니다.

또한 사용하지 않는 필드를 완전한 객체 상태로 만들어주기위해 불필요하게 많은 추가 쿼리가 발생할 수 있어서 이런 경우는 별도 값(dto)객체를 쓰는 게 나을 거 같은데 실무에서는 어떻게 하는지 궁금합니다!

kotlin spring-boot 도메인 dbms/rdbms backend

답변 3

제미니

지식공유자

안녕하세요 질문 감사합니다!
이건 사실 실무에서 딱 정해진 전략보다는 회사/팀 별 선호하는 스타일이 있는 편 인것 같습니다!
(결국 1,2번 모두 트레이드 오프가 있는데요 클래스가 계속 늘어나게 할것이냐, 개념 객체가 일부 데이터가 비어있는걸 허용할것이냐의 문제(불완전한 상태로 돌아다님))

그치만 저는 일반적으로 1번, 2번 모두 선호하지 않습니다!

왜냐면 1번의 경우는 자칫하면 Web, APP의 요구사항을 맞추기 위한 클래스가 계속 무수히 생기는 경향을 만들 수 있기 때문입니다

2번은 당연히 개념객체가 어떨때는 채워져있고, 어떨때는 비어져있고 이건 예측 가능성을 떨어트리기 때문에 좋은 선택지가 아니라고 생각합니다

그래서 저는 가급적 개념 객체를 다 채우는 것을 선호합니다, 그리고 개념에 대한 클래스들이 잘 생성 되어있다면 대부분의 경우 데이터 조회 후개념 객체의 필드를 다 채우는 것이 그렇게 큰 비용이 아닐 것 입니다.

그래서 Service 영역에서 리턴할 경우는 개념객체를 리턴하도록하고, 만약 API에 일부 필드만 응답 해야한다면 그건 Controller(Presentation Layer) 에서 처리하도록 구현하는 편 입니다!

그리고 만~약 클래스를 추가한다 하더라도 그 기준이 개념의 응집도를 최대한 우선 시 하는 편입니다!
(Page 응답을 위한 DTO 클래스를 만드는 것 전에 한번 응집에 대해 검토한다는 의미)

다만 이건 제가 더 선호한다는 것이지 1번,2번 모두 틀린 것은 아닙니다!
실무에서는 이것에 대해서 굉장히 회사마다 팀마다 다른 전략을 선택하기에 한가지 전략은 아니라고 봐주시면 될 것 같습니다!

모쪼록 답이 되었길 바랍니다! 감사합니다! 😃

우으어으

질문자

자세한 답변 감사합니다! 개념 객체를 잘 구성했다면 쿼리로 조회할 때도 억지로 관련없는 데이터를 추가적으로 채워넣는다는 느낌이 드는 경우가 확실히 적겠네요..!

인프런 AI 인턴

안녕하세요, 인프런 AI 인턴입니다. 우으어으님.

개념(도메인) 객체와 DTO의 사용에 대한 질문은 개발자가 취해야 할 전략과 관련해 중요한 주제입니다. 다음은 두 가지 옵션에 대한 간단한 설명과 실무에서의 적용 사례입니다.

1. DTO 객체 사용

DTO(Data Transfer Object) 사용의 장점:
- 효율성: 필요한 데이터만 전송하므로 호출 성능이 개선될 수 있습니다.
- 유연성: 특정 API나 조회 방식에 맞춘 데이터 형식을 가질 수 있습니다.
- 의존성 최소화: 도메인 객체의 변동에 영향을 덜 받습니다.
실무에서의 사례: 대부분의 대규모 프로젝트에서는 이미 사용 중인 다른 시스템과의 통신을 위해 DTO를 자주 사용합니다. 이는 특히 외부 API 호출 시나 다수의 필드가 불필요한 경우에 많이 사용됩니다.

2. 도메인 객체 일부 반환

도메인 객체 사용의 장점:
- 일관성: 도메인 모델 상태의 일관성을 유지할 수 있습니다.
- 추가 로직 필요: 해당 객체가 다른 로직을 포함해야 할 때 직접적 사용이 용이합니다.
실무에서의 사례: 빠르게 변하지 않는 안정화된 도메인 모델을 가진 영역에서는, 작은 팀이나 초기 단계 프로젝트에서 적용할 수 있습니다. 그러나 불필요한 데이터 전송을 유발할 수 있어 주의가 필요합니다.

결론 및 추천

당신이 제시하신 대로 목록 조회 시에는 성능 최적화를 위해 특정 필드만을 포함하는 DTO를 사용하는 것이 좋습니다. 도메인 객체를 완전하게 생성하는 동안 발생할 수 있는 추가 쿼리를 줄임으로써 애플리케이션의 성능을 최적화할 수 있기 때문입니다.

실제로 두 접근 방식이 모두 필요할 수 있습니다. 따라서 프로젝트의 요구, 팀의 관례, 성능 요건 등을 고려하여 결정해야 합니다. 관련된 논의는 Controller에서 비즈니스 로직 흐름이 나타나는 것에 대하여.. 질문에서 유사한 장단점에 대해 더 많은 정보를 얻을 수 있습니다. 이를 참고하여 팀 내에서 적절한 기준과 전략을 세워 가는 것이 좋습니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.

인프런 커뮤니티 질문&답변