Beautifully answered! I would like to accept, but first some comments:1. I do think the toDTO() is great, bcuz ur not accessing the get/set, which allows u to change the fields given to DTO w/o breaking existing code. 2. Say Customer has enough behaviour to justify making it an entity, how would u access props to modify them, e.g. address/tel change etc.

@IntelliData 1. When you say "change the fields", you mean change the class definition or mutate the data? The latter can just be avoided by removing public setters but leaving the getters, so the dto aspect is irrelevant. The former isn't really the (whole) reason that public getters are "evil". See programmers.stackexchange.com/questions/157526/… for example.

@IntelliData 2. This is difficult to answer without knowing the behaviour. But probably, the answer is: you wouldn't. What behaviour could a Customer class have that requires being able to mutate its telephone number? Perhaps the customer's telephone number changes and I need to persist that change in the database, but none of that is the responsibility of a behaviour-providing domain object. That's a data-access concern, and would probably be handled with a DTO and, say, a repository.

@IntelliData Keeping the Customer domain object's data relatively fresh (in sync with the db) is a matter of managing its lifecycle, which is also not its own responsibility, and would again probably end up living in a repository or a factory or an IOC container or whatever instantiates Customers.

I mean change class definition; even exposing getters only can be a problem: say I have several functions calling getDTO() on the object, I can always change the fields being exposed via getDTO() w/o breaking the code; however, if I do getProperty(), then if I remove the property later on I will be breaking the code in many places.

@IntelliData Yeah I understand. I agree toDTO it may mitigate that, but as I mentioned in the comment, there are other problems (violation of "Tell, Don't Ask"), which it does not.

1. 'Tell, Don't Ask', good point; however, if I say provideDTO(), is it in effect 'Tell' even though it returns something? (Yeah, I know it's only a semantical difference.) 2. If a behaviour providing Customer also has data, whose responsibility is it to change the data if necessary?

In general, would u say that 'Tell Don't Ask' means never return data? How is that possible?

No, I don't think Tell Don't Ask means never return data.

I don't like the name Tell Don't Ask precisely because of that kind of confusion. When I hear "tell" I think of commands (change state, don't return data) and when I hear "ask" I think of queries (leave state the same, return something). But that's not what they refer to in Tell Don't Ask

If you really, really just need the data (e.g. you want to print a customer's name to the screen), then a dto is perfectly appropriate. Tell, Don't Ask isn't relevant in that situation

But if the data exists only to aid some kind of behavior, it's much preferred to have the class that holds the data provide the behavior instead of the data, if possible. That's what Tell Don't Ask is essentially about.