DTO에 대한 고민

사건발생

MVC 패턴을 사용하여 개발하고 있는 프로젝트에서 리팩토링 및 수정할 내용이 있어서 Dto쪽을 수정하게 되었다. 구글링을 통해 흔히 볼 수 있는 게시판 프로젝트이기 때문에 도움도 구글링을 통해 많이 받았는데 우선 되게만 작동하자는 마음으로 많은 블로그에서 사용하는 것처럼 DTO 하나로 View → Controller → Service 까지 넘기게 되었다. 이러한 정신나가는 결합도로 인하여 기술 부채를 정면으로 마주하게 되었다… 한두개도 아니고 이러한 패턴을 몇개 수정하니 DTO의 역활이 이게 맞나 싶기도하고 Entity를 직접 넘기는 방식을 사용하기에는 도메인 Model을 외부에 노출시켜 보안문제를 야기할 수도 있다. 이참에 알아보도록하자

 

 

의문

DTO란 Data Transfer Object의 약자로써 데이터 교환을 목적으로 사용하는 객체이다. 하여 계층간의 데이터를 전달할때 DTO를 사용을 하게 된다.

그렇다면 각 레이어에서 데이터 반환할때 마다 DTO를 사용해야 하기 때문에 레이어마다의 DTO가 정의 되어야하는 것일까?

레이어 이외에도 기능별(ex CRUD)로 DTO도 정의 되어야하는 것일까?

한 로직이 진행될때 각 레이어에서 전달되어지는 레이어의 값들은 크게 달라지지 않을 것은데 불필요한 중복코드들을 남발하게 되는 것은 또 아닐까?

만약 레이어별 DTO를 만들게 된다면 각 DTO들의 변환되는 곳은 어디서 정의 되어야하는 것인가?

각 DTO들이 변환되는 것을 DTO 내부에 정의하게 되면 DTO간의 결합도가 발생을 하는데 혹을 떼려다 다른 곳에 붙이는것은 아닐까?

DTO를 많이 나누지 않았을때 DTO와 Entity간의 결합도를 낮추는 방법은 없을까?

머리가 지근거리고 정말 골때린다

 

 

 

도움

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

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

[Tecoble] DTO의 사용 범위에 대하여

[Tecoble] DTO의 사용 범위에 대하여

잊을만 하면 돌아오는 정산 신병들 | 우아한형제들 기술블로그

잊을만 하면 돌아오는 정산 신병들 | 우아한형제들 기술블로그

DTO의 사용성과 매핑 전략에 대해

DTO의 사용성과 매핑 전략에 대해

 

결론

DTO에 관한 고민을 했던 사람들의 기록, 커뮤니티의 자료들이 많이 남아 있어서 도움을 많이 받게 되었다. 우형 신입개발자님의 정리에서 Controller에서 Service로 데이터를 전달하는 과정에서 외부 API를 호출할 수도 있기 때문에 추가적인 DTO를 사용하는 것이 결합도도 낮출 수 있기 때문에 좋을 수 있다. 라는 내용도 있었는데 아직 Service에서 외부 API 호출에 대한 경험이 없어 이 부분은 생각해보지도 못했던 부분이었고, 프로젝트에 사용되어 왔던 Layered Architecture외에도 나중에 공부해 볼만한 Hexagonal Architecture라는 구조도 알게 되었다. 결국엔 DTO를 만드는 것은 정답이 없고 장단점을 이해하고 프로젝트 규모와 팀일경우 팀원과의 조율을 통하여 범위를 결정할 수 있는 능력을 키우는 것이 중요하게 느껴졌다.

이번 프로젝트에서는 모든 레이어에서 공통으로 사용하는 One-Way Mapping 방식에서 편하게 사용하다가 문제가 생겼기 때문에 중복코드가 다수 발생할 수 있지만 혼자 열심히 DTO를 찍어내면 되기 때문에 이 부분을 감안하고 최대한 DTO 맴버변수들을 타이트하게 가져가도록 설계 해봐야겠다.