DTO.. 예전엔 VO로 더 많이 불렸었다...
DTO가 초기에 design pattern으로 인기를 얻은 것은 coarse-grained 방식의 EJB 접근법이
한창 주가를 올리던 EJB의 절정기때였다.
EJB client가 fine-grained방식으로 remote call을 EJB에게 자꾸 보내는 것은 매우 많은 부하를 주고
리소스를 낭비한다는 지적아래 Entity Bean을 client에게 직접 노출하는 것을 피하고
session bean(주로 session facade)를 통해서 Entity Bean의 정보를 DTO구조의 클래스를 사용해서
정보를 카피해서 client로 전송하고 전송받는 가장 대표적인 EJB구조이다.
난 이것도 모르고 공군 중전소에서 개발할때....DTO를 막 써댔다...-_-;;

사실 DTO가 사용된 이유는 Entity Bean을 serialize해서 client에 보낼 방법이 없었기 떄문이란다...
setter/getter를 가진 DTO를 Entity Bean과 별도로 만들어서 일일히 Property 별로 복사를 해주는
코드를 일일히 작성해야했다. 현재 InnoERP개발중인데... 이러한 문제가 똑같이 존재한다...
Domain Model하고 똑같은 DTO를 만들어서 복사를 해줘서 client로 전송하고 전송받아야 했다.
물론 지금은 reflection을 사용해서 자동으로 이름을 비교해서 복사해주는 serializer, deserializer 객체를
만들어서 사용중이다. 하지만 이방법은 상당한 부하를 가져다 준다.

후에 EJB가 인기가 떨어지고 대안 기술들이 나오면서 DTO무용론이 제기됐다.
DTO는 쓸데없는 패턴이니 사용을 자제해야 한다는 것이다. 이러한 주장을 가장 많이 한 쪽은
POJO기반의 Domain Model을 지원하는 Hibernate와 ORM쪽이였다.

Hibernate는 POJO기반의 Domain Model을 지원하기 떄문에 DTO를 사용하지 않고 view,controller등에서
Domain Model을 직접 사용하는 것이다. 이 방법이 바로 Domain Model Everywhere이다.

더 나아가서 ActionForm같은 폼데이터클래스를 사용하지 않아도 되는 Webwork나 SpringMVC에서는
Form데이터를 바로 Domain Model 오브젝트에 받아서 사용한다.
SpringMVC에서는 자동으로 Form데이터를 DomainModel로 변환시켜주는 기능을 제공한다.


반면에 DTO를 사용해야 한다는 주장은...
Domain Model은 순수하게 Domain Logic만 가지고 있어야지 Presentation Logic을 가지고 있어서는 안된다는
주장이다. 사실 Presentation Layer사용할 목적으로 getter를 만드는 경우가 많다.
Domain Model안에 있는 데이터들을 가공해서 말이다.
이러한 방식은 모델링의 순수성을 깨고 Domain Model Object를 망가뜨리게 된다는 것이다.
또, Domain Model을 복잡하게 조합한 형태의 Presentation요구사항들이 있기 때문에 Domain Model을
직접 사용하는 방식은 한계가 있기 마련이다.

현재 진행중인 내 개인 프로젝트 MoneyPlanner에서는 Domain Model을 view에서 그대로 사용하는데...
Presentation과 Domain Model의 갭이 좀 큰경우에는 DTO를 따로 작성해서 사용했다.

내 생각엔 크게 벗어나지 않으면 필요시에 DTO를 만들어서 사용을 하는게 좋은거 같다.
별일 없으면 Domain Model을 그냥 사용하고 말이다.


좀더 고민해봐야 할 문제...
AOP를 이용해서 Domain Model을 확장하는 문제
Abstract Domain Model, Interface 기반의 Domain Model방식