A common misconception about Data Transfer Objects is that they transport data between layers of an application, and people infer this to mean between layers of an application that exist in the same running process.
DTOs were conceived as a means to transport data between processes. When data is transmitted from one process to another it gets serialized into another format. Text based formats like XML or JSON are most popular (think "web services" here), but other formats exist as well, and can be specific to the two processes exchanging communication. DTOs are basically handy bags of data that represent a whole bunch of parameters in a single variable, instead of tracking all the parameters in separate variables.
The Rich Domain Model ends where the running process of the application ends. It begins again in another process, but that is a separate Rich Domain Model. The DTO is an application specific rendition of that transported data. You would need to write code that maps DTOs to your Domain objects, which makes this transmitted data compatible with your own Rich Domain Model.
When you're working with a remote interface, such as Remote Facade (388), each call to it is expensive. As a result you need to reduce the number of calls, and that means that you need to transfer more data with each call. One way to do this is to use lots of parameters. However, this is often awkward to program - indeed, it's often impossible with languages such as Java that return only a single value.
The solution is to create a Data Transfer Object that can hold all the data for the call. It needs to be serializable to go across the connection. Usually an assembler is used on the server side to transfer data between the DTO and any domain objects.
Source: Data Transfer Object by Martin Fowler
ExpenseSearchDTO