DTO에 무엇을 담아야 적절할까?

자바 - 스프링 프레임워크 혹은 스프링 부트를 기반으로 사용했다면 DTO, VO, Entity 등 필요한 값만 정의한 객체를 흔히 봤을 것이다.

만드는 것은 정말 단순하지만, 응용하기에 따라서 DTO, Entity 등 영속성과 변동성 문제 때문에 역할을 나누는 등 DTO 하나를 가지고 여러 방법으로 정의할 수 있다.

 

내가 실질적으로 여러 번 만드면서 고민한 것은, 과연 DTO에는 어떤 값이 들어가야 적절한가?

이것이다.

 

1. DTO

 

기존에는 로직처리에 들어가는 모든 값을 담으면 객체 하나로 필요한 변수를 모두 파악할 수 있으니 편하리라 생각했다.

하지만 기존에 딱 전달할 데이터만 담아서 만든 프로그램의 경우는 위와 같은 방법으로 하면 왜 필요도 없는 정보를 DTO에 담는지 의문이 든다는 말을 들었다.

 

확실히 DTO가 데이터를 전달하고자 하는 목적으로만 쓰인다면 굳이 로직 내부에서만 사용되는 변수를 딱히 담을 이유는 없다.

하지만 여러 로직을 사용하여 값 A를 얻고 -> 값 A를 매개변수로 값 B, C, D를 얻고 -> .... -> 최종적으로 값 Z를 출력

이런 방식에서 딱 전달할 값만 담는다면 DTO를 보고 해당 내용을 이해하기는 다소 시간이 걸렸다.

 

2. 은닉성

 

그래서 일부러 내부 계산 값을 DTO에 담아서 정리해봤다. 길어졌지만 순서대로 어떤 값들이 적용되는지 한 눈에 들어왔다.

하지만 이게 객체지향적인 설계가 맞을까? 하는 의문에 다시 객체지향을 공부하다가 은닉성이라는 측면을 다시금 생각하게 되었다. 

DTO는 외부에서 정보를 확인할 수 있다. 그 때 로직 내부에서 사용하는 변수의 이름이나 값을 확인할 수 있는 것이 과연 적절할까?

보안적인 측면에서는 NO라는 생각이 들었다.

 

3. 다시 DTO 본연의 역할로

 

한 번 시행착오를 겪으니 DTO가 왜 정보 전달 객체인지, 그 이름을 다시금 새겨듣게 되었다.

DTO는 오로지 다른 객체가 필요로 하는, 혹은 출력에 필요한 정보를 담을 뿐이다.

Entity도 DBMS와 정보를 주고 받기 위해서 별도로 분리됐다는 사실을 인지했다.

 

이름에는 그 목적이 담겨있다.

튜닝의 끝은 순정이듯, 이것저것 해보다가 결국 이름을 보니 그것이 왜 그러한지 알게된다.