DTO stands for Data Transfer Object. A DTO is a class which is more a data structure than a real class, usually, and which is created to transfer information from one layer to another, often across the network. It's not a model entity.
A DTO is often used
- when serializing real model objects is not paractical (because the structure doesn't fit, or because the receiver doesn't have access to Hibernate classes, or because lazy-loaded entities are a problem)
- when you want to transfer information that is an aggregation, or a complex view, over your model objects (like data of a statistical report for example)
So naming your entities DTO is not a good idea. DTOs and entities are different things. The Model
suffix is also cumbersome. Entities are usually named after what they represent: Customer
, Company
, Player
, Order
, etc.
Segregating classes based on their technical role is an often used solution. But it tends not to scale when the application grows. I usually have a first level of segregation based on a functional aspect (like customer management, order management, security, etc.), and then a second level based on technical aspects (service, dao, model, etc.)