I don't totally agree on the answer by Robert Harvey, I think Data Domain Objects (DTOs) should be separated with Presentation Layer's Objects.

Firstly for security reasons, which is you do not want to expose your inner data structure to the outside world and you shouldn't, and presentation layer object gives you the opportunity to limit the response data to what is REQUIRED ONLY.

Secondly, security aside, if you are in a world of microservices or distributed services, or your application is designed in modular, then segregation of interfacing and data objects are making more sense.

Even some might say my application is small, and I just want to get it out fast without all the boilerplates, well you can, but I'll not advise, that's the experience telling me not to do so. We have seen a lot of these examples in the past, RoR, NodeJS, ... you named it.

The thing is, they'll get you somewhere really fast, but only resolving simple things in a simple way, but complex things will be made unpractically complex.

So for me, I'll say rather follow the best practices from the beginning, and worry less later than to scrap the whole thing and redo, and trust me you'll gonna spend the same (if not more) amount of time to get it right later.

I think Data Domain Objects (DTOs) should be separated from Presentation Layer's Objects.

Regarding "Data Transfer Objects are Shame", I read such articles about anti-pattern and so on, I think people are just being lazy to say so, because they wanna write fewer codes and might not really understands why the design pattern is there in the first place.

Firstly for security reasons, which is you do not want to expose your inner data structure to the outside world and you shouldn't, and presentation layer object gives you the opportunity to limit the response data to what is REQUIRED ONLY.

Secondly, security aside, if you are in a world of microservices or distributed services, or your application is designed in modular, then segregation of responsibility and data objects are making more sense.

Imagine this: you have 3 libraries for restful,

• A. user api (the service interface) - depends on B
• B. user data objects
• C. user provider (the real implementation) - depends on A & B

and 3 libraries for data storage layer (there should be a business layer in place, but I skip that for simplicity)

• D. user data service (interface) - depends on E
• E. user data objects (DTOs)
• F. user data service provider (implementation) - depends on D & E

So imagine you are having another data service module which wanna use user data object only, it should depend on library E only; then if there another restful service that wants to borrow user data objects, they can just depend on B only. And so on, things should be transparent and as atomic as possible, and that promotes code reusability.

Even some might say my application is small, and I just want to get it out fast without all the boilerplates, well you can, but I'll not advise, that's the experience telling me not to do so. We have seen a lot of these examples in the past, RoR, NodeJS, ... you named it.

The thing is, they'll get you somewhere really fast, but only resolving simple things in a simple way, but complex things will be made unpractically complex.

So for me, I'll say rather follow the best practices from the beginning, and worry less later than to scrap the whole thing and redo, and trust me you'll gonna spend the same (if not more) amount of time to get it right later.