DTO의 사용범위 / Entity와의 변환에 대한 논의

DTO - Entity간의 변환에 대해

Entity To DTO Conversion for a Spring REST API | Baeldung
A Better Way to Project Domain Entities into DTOs

먼저 첫번째 링크는 ModelMapper API를 이용한 Entity와 DTO간의 기본적인 변환 예제를 보여주고 있다.
DTO의 기본적인 사용방식과 레이어간의 흐름을 볼수있다.
여기선 Controller에 ModelMapper를 호출해 Entity~DTO간의 변환을 수행하는 로직이 위치하는것을 확인할수있었다.

두번째 링크도 DTO로의 변환로직을 어디에 위치시켜야 하는가에 대해 논의하고 있다.
이 글의 결론은 Repository안에 위치해선 안되고, Application Service에 위치해야 한다고 말한다.
참고로 이 글의 세줄요약은 다음과 같다.

1. DTO Assembly(DTO 변환)의 역할을 Repository가 책임지게 하지 말라
2. DTO Assembly는 Domain 레이어의 aggregates를 DTO로 변환해 Presentation 레이어로 전달한다
3. DTO Assembly는 Application Service에 위치한다

=> 다소 상충되는 부분이 있다. Presentation Layer인 Controller단 vs Service Layer 어디에 위치해야 할까?

일단 둘다 공통적으로 Repo단 이후로는 지양한다. 그럼 결국 DTO를 어디까지 사용해야할까?

DTO의 사용범위

DTO는 어느 레이어까지 사용하는 것이 맞을까?

참고할만한 자료

Should services always return DTOs, or can they also return domain models?

Service가 무조건 DTO를 반환해야하는지 or Domain model도 반환해도 되는지? 에 대한 질문
즉, 도메인 모델이 서비스 레이어 이후로 노출되어도 되는지에 대한 논의다.

역시 이곳에서도 명확한 정답을 단정짓진 않고 다음과 같은 말들을 해준다.

• 서비스 레이어는 application의 경계를 정의하고 도메인을 캡슐화한다. 즉 도메인을 보호한다
• 무조건 DTO를 반환시키기로해서 엄격하게 DTO를 고수한다면, 서비스 레이어에 DTO를 정의해야하는가? : 네
• 메인 질문 : (당연한 말이지만) DTO는 말그대로 데이터 전달용 객체이고, communication에 사용된다면 의미가 있다. 대신 Presentation 레이어에서 도메인 모델을 사용하게되면, 결합도가 증가해 코드변경이 불가피할수있다
• 도메인 모델과 똑같은 DTO를 만드는것 같고 의미없게 느껴진다 : DTO의 단점중 하나이다. 대신 지금은 코드중복으로만 생각되지만, 나중에 프로젝트가 확장되면 더큰 의미를 발휘할 수 있다.

Reference 요약

• DTO를 사용하는 경우 : 대규모 프로젝트
• DTO를 사용하지 않는 경우 : 작은 사이즈의 프로젝트
• DTO에 대한 논쟁, 단점
  • 코드 복제의 관점
  • 추가적인 개발/디버깅 비용 등
  • 매핑, 즉 동기화 필요
• DTO의 장점
  • 도메인과 프레젠테이션의 분리
  • 데이터 교환 overhead 감소 (DTO 본목적)
  • 인터페이스, API 안정성

---

결론

지금 수준의 내가 함부로 결정짓기 어려운 주제다.
본문에 언급하지않은 내용까지 이것저것 고려해 내가 일단 내린 결론은 다음과 같다.

• 기본적으로는 DTO를 Controller단까지 사용한다
• 하지만 상황에 따라선 Service까지 끌고가도 괜찮지 않을까?
• 단 무조건 습관적으로 DTO를 만드는건 주의하자. 상황에 따라 DTO가 필요없을수도있다.

---

본 포스팅을 작성하게된 배경인, 로또미션의 아래와 같은 피드백들을 참고하면 실제로 적용할때 좀더 와닿는다.

---

2020.10 UPDATE

친구에게 비슷한 질문을 받으며, 다시 정리해본 현재의 생각은.

• DTO의 Repo단 진입은 다들 공통적으로 지양.
• 서비스 반환 타입 : DTO vs Model
  • 코드 복잡성 but 도메인 모델의 보호와 안정성의 Trade-off.
  • 이 부분은 위에서 언급한 장단점으로 충분히 이해되며, 상황에 따라 취사선택
• DTO 변환 위치 (위의 표현으론, DTO Assembly)
  • Presentation(ex. Controller) vs Service
  • DTO를 어짜피 쓴다면 굳이 Controller에서 할 필요는 없을 것 같다. 서비스에서 하면서 도메인 모델도 보호해버리는게, 겸사겸사?
  • DTO는 결국 레이어간 전달용이므로, 양쪽 어느곳이라도 크게 중요하지 않을 것 같음.
• 앞으론 'DTO의 사용범위'란 고민보다, '도메인 모델 보호'의 관점에서 생각해보자.