Difference between Transfer objects and Domain objects

Question

Could you please explain the difference between Transfer objects and Domain objects in simple terms ? And if u could give a Java example, that would be great..

Irretentive

Answer 1

• DTOs don't have any logic. They only have fields (state). They are used when transferring data from one layer/subsystem to another
• Domain objects can have logic (depending on whether you are using domain-driven design or have anemic data model) and they are usually related to the database structure.

If using anemic data model (i.e. your domain objects don't have any logic), DTO and domain object can be the same object.

Related: http://techblog.bozho.net/?p=427

Connected

No. Domain objects have no specific relation to any persistence. In simple words, they are parts to ensure the business logic required to run the application. In most cases you can and should create your app without persistence in mind. For example, work with in-memory objects and fake repos at the beginning. – Picklock

Answer 2

A Data-Transfer-Object (DTO) is used to exchange data between different parts of an application (such as different layers), or different applications.

• DTO's are simply a "dumb" data structure.
• They are used in contracts / interface definitions - this means that any component that uses one of these interfaces "knows" about these objects.

Domain Objects (DO) (and the classes from which they are derived) implement business logic, as such they are only located in the Business logic layer / Domain (the essential meaning is the same even if the terms are different).

Because DO's implement business logic they can be complex, and can include methods, events and so on.

One more point about DTOs

According to the Martin Fowler school of thought a DTO is a combination of several objects (each of which would be what most people would commonly call a DTO); the rationale is that in situations it's less expensive to send larger packages of data less frequently (as opposed to being "chatty" and sending many small packages constantly across the wire).

So where most people would view a DTO as a single object Martin F is saying a DTO is simply an "envelop" that contains several discrete (and possibly unrelated) objects. Not a big issue IMO - most people take the view that a DTO is as per my definition at the top of this answer (or something close to it).

Olcott

Thanks for your reply. Does it mean that DTOs are used primarily towards the presentation layer, while DOs are used towards the backend only ? – Irretentive

No, DTO's are not restricted towards the Presentation layer. – Olcott

+1 dto are generally used across tiers, however it is not limited by that. – Religion

Answer 3

Transfer objects are often serializable due to the nature of its use, this is especially pertinent if the calls are remote and between JVM, or they will be used in a way that promotes serialization, such as stateful session beans. For this purpose, transfer objects must be susceptible to such "treatment", I.e. Transfer objects implement serializable.

The reverse may not be said of domain objects. Domain objects may contain behavior, however DTO are merely a transportation medium.

Religion

Answer 4

Domain object in business perspective, it is actor or subject of the activity with whole domain and flows, DTO is the data object which is not the same as data bean that faithfully to reflect database objects (especially at ORM architecture) DTO can has data aggregation, transform , combination to satisfy the representation or some data munipulate needs , it is no subject , but Domain object has subject base on their domain level defination

Fils

Did this add any value to the above answers? – Olenta