What drives the design of a data transfer object?

Question

I am writing a web service. I am also writing a web client which uses this web service. I've experienced some of the pain of trying to send domain objects over the wire (cyclic references, lazy loading, etc. -- see e.g. Davy Brion's post on why it's a bad idea). So, I am going to use DTOs to transfer between these two tiers.

Being in charge of both ends, I am able to control the design of the DTOs. Now I'm wondering, what drives the design of the DTO? Is it the user interface on the client-side? Do I create DTOs based on what views/screens the client will have? Or it something service-side that should dictate the contract of the DTOs I send out, and the client has to work with what it's given?

Answer 1

I think in many cases the DTO model is not that important as the domain model, so I'm very pragmatic in this issue. We are writing DTO very close to what the client actually needs, because it is the only consumer. (There are processes calling the server, they are using different DTO's.) There could even be different DTO's for different views to the data. That's the power of the DTO's.

To be clear: it should be driven by what the client needs, not client-specific. For instance, use general data types, not view-specific data types. Not every change (eg. UI design change) on a view should result in a change of DTO's. This is a general rule of maintainability, nothing special.