DTO (Data Transfer Object) in Domain Driven Design

DTO (Data Transfer Object)is a very common used pattern in enterprise applications. Martin Fowler also documented it in his class book “Pattern Enterprise Application Architecture“. In the meanwhile, DTO is also a very famous “Anti-Pattern”. The pure OO purist think DTO is a devil. It is so easy to build. The object become nothing but a simple data container, which represent the data in the tables instead of the real domain objects. The business logic embedded in the application is going to shift from middle domain logic tier to tables, most of time spreaded among the stored procedures, which is leading to a unmaintainable solution.

So should we give up DTO totally in our application design? Absolutely not, in the other end, I find DTO still useful especially in UI and UI process layers. For example, we have a complex searching page to find customer by first name, last name, SSN, address, phone, email, and so on. those information may stay in different domain objects. It is also very hard to design a method with a very long list of parameters, not just ugly but also unmaintainable. My approach is to design DTO object pass data between UI and UI process (Presenter or Controller). Then access the service objects, and domain objects from presenter/controller. So I can design domain entity with the interfere from the special requirement of UI. Again it is important to implement MVP pattern to protect the domain object, which is also one of the important principles I heard from DDD: don’t leak business logic out of the domain object layer.