Hi Maxi Contieri, indeed, I guess your point make sense in this particular programming paradigm. I can understand your point when talking about Employee class, EmployeeDTO, EmployeeDAO and in a classic OO multi tier application. Functional Programming have a different usage of DTOs and serve at the foundation of their Algebraic Data Types. They are no code smell at all in this context :p

Hi Maxi, thanks for sharing your though on the subject. I have to say, I do not agree with your analysis on the DTOs for the following reason: 1) In the list of Problems you mention the following Anemic object: Well DTOs are object in the sense they are instance of a class BUT their purpose is not to provide any other feature than transporting information. NOT logic. As such their roles is to serve as projection of data. They are containers. This would be like saying a Tuple is anemic.... Inconsistent data: From what angle? They are not suppose to be the source of any data. they are suppose to be used to transport data. Duplicated Logic: They cannot have any logic. They are object but they should be immutable. They are simply a tool to model parameters in an API. They should not be confused to Value Object... Duplicated Structure: Again they are there to serve as container with predefined structure. They no not represent "Entities" or "Value Object". They are used to transfer data between one system, world, model.. to another... Class poluting: I do not understand that point. You will probably model them using a class. Do you mean poluting the entities of your model? Then again they should not be part of your model as such... They are part of the contract or the api your model expose. as a mean to structure the API of your model for example...) I will not comment on every point of your assumptions as I believe their were listed based on an wrong use of the DTOs. My point is DTOs are predifined tuples. No logic. Just a tool to define a projection of your famous "object". If you start adding logic on them then I guess you are building something closer to a Value object or ADTs in FP. When building API (Not limited to inter system api but also apis for other "objects" they are pretty handy to structure this API. thanks again for sharing your view. Alex.