DTO(Data Transfer Object) 논쟁

 

어플리케이션을 개발할 때 각 계층 사이에서 데이터를 어떻게 주고 받을지에 대한 전략을 세우는 것은 어플리케이션을 개발하는데 있어서 상당히 중요한 부분이다. 이 전략이 어떻게 수립되느냐에 따라 개발시 생산성과 유지보수 용이성에 큰 영향을 미치기 때문이다.

 

EJB 아키텍처에서는 데이터를 전달하기 위한 방법으로 도메인 모델 데이터를 직접 전달하지 않고 DTO와 같은 새로운 모델 클래스를 생성하여 전달하는 것을 최고의 원칙(Best practice)로 추천하고 있다.

 

 

 

DTO 패턴

 

DTO 패턴은 속성과 gettet/setter 메소드로 구성된 자바 클래스 패턴을 말한다. 객체는 상태(state)와 행위(behavior)로 구성됨이 기본 원칙이지만 데이터만을 가지는 데이터 홀더의 개념과 단순 오브젝트로 구성된 도메인 모델 객체이다. EJB 아키텍처에서 이와 같은 패턴들을 사용할 수 밖에 없었던 이유로 분산 환경하에서 원격 호출시 많은 비용이 발생하기 때문에 원격 호출의 수를 최소화하기 위한 방법으로 이 패턴의 사용을 적극 권장하였다. 이 방법은 각 계층간의 데이터 전달을 위한 최선의 선택으로 추천되고 있지만 다음과 같은 문제점도 가지고 있다.

 

 

 

DTO 패턴의 문제점

 

도메인 모델에서 DTO 모델로, DTO 모델에서 도메인 모델로 데이터를 전달하는 과정에서 데이터가 유실될 수 있고, 이와 같은 문제로 인한 버그는 디버깅하는데 상당히 많은 시간이 소요된다. 또한, 도메인 모델을 DTO 모델로, DTO 모델을 도메인 모델로 전달하는 추가적인 작업이 발생함으로써 추가적인 비용이 발생한다. 이는 관리해야 할 클래스가 많아짐으로써 유지보수가 힘들어지게 되며, 프로젝트에 따라 다르지만 DTO 클래스의 수가 도메인 모델 클래스 수의 두 세배 이상 되는 경우도 볼 수 있다.

 

이와 같은 문제점을 가지고 있음에도 이 패턴은 EJB를 사용하지 않는 Non EJB 아키텍처에서도 남용되고 있다. 물론 Non EJB 아키텍처에서도 효율적인 데이터 전달을 위해 DTO와 같은 별도의 클래스를 만들어 전달할 필요가 있을 수도 있지만 그와 같은 경우는 그리 많지 않다.

EJB를 사용하지 않는 Non EJB 아키텍처와 Ligthweight 컨테이너 아키텍처에서는 계층 사이에 데이터를 전달하기 위해 도메인 모델 클래스외에 별도의 DTO를 만들 필요가 없다. 각 계층 사이의 메소드 호출을 몇 번 더 실행한다고 해서 추가적인 비용이 거의 발생하지 않는다. 만약, 각 계층 사이에 너무 잦은 메소드 호출로 애플리케이션의 실행 속도가 저하될 것이라고 걱정하는 개발자가 있다면 DTO를 만들 시간에 데이터베이스 쿼리를 튜닝하는데 시간을 투자하는것이 훨씬 더 좋은 성능의 향상을 얻을 수 있다.

  
또한, DTO는 빈약한 도메인 모델(Anemic Domain Model)이라고 하면 DTO 사용에 대한 논쟁이 있다.

 

 

 

DTO의 빈약한 도메인 모델의 대한 논쟁

 

빈약한 도메인 모델(Anemic Domain Model)은 데이터만 가지는 데이터 홀더 개념의 단순 오브젝트로 구성된 도메인 모델로 객체지향 언어의 기술의 장점을 전혀 살릴 수 없는 한계를 가지고 있다. 빈약한 도메인 모델은 단순한 VO 객체를 뜻하며, 객체란 상태(state)와 행위(behavior)로 구성되어 있어야 한다라는 기본 개념에도 맞지 않는다. 따라서 구조적으로 불합리한 형태의 코드를 생산하게 한다. 모든 도메인은 행위에 해당하는 로직을 가지고 있고, 그 로직을 어떠한 형태로든 나타내야 하는데 그것이 도메인의 상태 정보만 가지고 있는 빈약한 도메인 모델에서 모두 빠져나와 다른 형태로 구성된다는 점이다. 대부분의 자바 엔터프라이즈 아키텍처가 가지고 있는 이런 구조적인 한계들은 결국 과도한 서비스 레이어의 사용을 부추긴다. 도메인 객체의 데이터홀더(Data holder)화와 서비스 레이어의 비대해짐은 결국 트랜잭션 스크립트 패턴의 형태의 코드를 양산하게 된다. 트랜잭션 스크립트는 각 업무 트랜잭션을 하나의 메소드에 한 번에 구성하는 형태의 패턴이다.

 

반면에 빈약한 도메인 모델은 반대하는 사람들은 풍성한 도메인 모델(Rich Domain Model)이나 지능적인 도메인 모델이라는 형태로의 전환을 시도한다. 풍성한 도메인 모델의 특정은 도메인 객체에 단순한 데이터 값의 저장을 위한 getter/setter가 아닌 도메인과 직접 관련이 되어 있는 로직을 담았다는 것이다. 제한적이지만 도메인에 극히 종속적인 로직은 도메인 오브젝트에 담았기 때문에 포터블한 도메인 오브젝트로 발전할 뿐더러 상당수의 로직 부분의 서비스 레이어에서 제거 될 수 있게 하는 좋은 효과를 가져왔다.

 

이렇게 도메인의 로직이 이동을 하게 되면 서비스 레이어에 중복되고 산재해서 나타나던 도메인 로직이 사라지고 일관성 있게 도메인 객체에 처리를 맞길 수 있는 형태로 발전하게 된다.

 

참조 : Spring 프레임워크 워크북 // 지은이 : 박재성, 한빛미디어