EDABlog

http://msdn.microsoft.com/en-us/library/ms978717.aspx
http://martinfowler.com/eaaCatalog/dataTransferObject.html

I still think Martin Fowlers description is best

An object that carries data between processes in order to reduce the number of method calls.

While DTOs were designed for the above they provide key benefits to distributed systems

1.Performance

Typically Objects in OO have quite a chatty interface , this is good for design purposes as these communication mirror the relationships between the objects however the performance implications for distributed systems are significant and worse the worry about performance last mentality in software development makes a significant issue as these issues are VERY expensive to fix as the design from the start is flawed. A simple example is Order and OrderItem while an order with a thousand line items may iterated the Items in memory in a microsecond  ( say to addup the total) ,  in a distributed system  with OrderItems in a different service this could take seconds (or more) . Much better to send all the Orders and OrderItems in one operation and then do the work required. While this is an obvious example most real life systems will have MANY issues with such chattiness which are not so easy to deal with.

2.Remove Leaky abstraction  from your domain model and hence improve maintenance

Another benefit of DTO's is they preserve your business logic from contamination by the needs of the outside world and hence make the system more easy to maintain. The performance issue mentioned above is one. Another common one is since you maybe communicating with other systems a change may be required in your system which if you are not using DTOs will propogate through the whole system ( eg support for DateTime? instead of Datetime for a Java client) . Its best to have a DTO be responsible for serializing the class ( and deal with the limitations of the transport eg XML). Is your Order class really responsible for its wire representation so why make it so ? Windows Communication Foundation doesn't support generics why limit your domain model by not allowing them , this is a perfect example of the leak abstraction you get with distributed systems - All such frameworks leak and hence you violate the basic OO rules of responsibility. Clearly your domain objects should NOT be responsible for working with the communications framework (whether EJB , Windows Communication Foundation etc) or underlying data ( eg XML) 
so why make it so?  Also note communication errors can occur in the middle of you business logic code ? Is it the responsibility for this code ? Preserving your domain model as designed will make it easier to maintain your code.  Leave the DTOs/Fascade to handle the real world.

3. Appropriateness of Domains

All systems have different ideas of  what a "Person" or "Car" is , while a single application domain does not have this issue as much the more clients and services you get the more it becomes an issue. This is especially true of SOA systems. By treating the information from the server as Data ( and Procedures) each application can have a unique view of what a "Person" and "Car" is and hence map its solution closer to its real world model rather than trying to force the real world model for a new part of the system onto the current application.   This is not really a DTO benefit but DTO's allow the more completes seperation of logic  eg the sever converts the DTO to its logic and the client does likewise. 

For example with  a client UI by exposing Domain objects to View layer, Views become aware of structure of domain objects, which lets the view make some assumptions about how related objects are available. For example if a domain object "Person" was returned to a view to which it is "bound" and on some other view, "Address" of Person is to be bound, there would be a tendency for Application layer to use a semantic like person.getAddresse() which would fail since at that point Address domain object might have not been loaded at point. In essence ( or require more chatty communication via lazy loading) , with domain objects becoming available to View layers, views can always make assumptions about how data is made available. Also the reverse when domain objects are bound to views (more so in Thick clients), there will always be a tendency for View centric logic to creep inside these objects making them logically corrupt. (note the similarity with the above messaging framework /wire transfer logic creeping in)


Easier to Maintain , better performance so why are DTO''s  rarely used in a lot of systems ? 

People seem obssessed with using tools and most tools ( and a lot of design methodologies) are focused in an idealized world and like to use the same object throughout the distributed system.  However real world practicalities then quickly reduce the quality of the domain model code. Such as focusing with serialization issues etc .

There are issues with use of DTO's also since use of DTO creates additional work in terms of creation of Assemblers (DTO to Domain objects and reverse), Proliferation of analogous objects like Patient domain object, Patient DTO ,PatientDTOConverter  ,PatientView ( if not directly bound) . However note each of these Patient domains has a clear roll and the objects themselves are easy to create.

I think DTOs should be used in ALL services unless you can write the service in a few days. Small anemic domains do not require them.