Short answer:
-
Entities may be part of a business domain. Thus, they can implement behavior and be applied to different use cases within the domain.
-
DTOs are used only to transfer data from one process or context to another. As such, they are without behavior – except for very basic and usually standardised storage and retrieval functions.
Long answer:
While the term “Data Transfer Object” (DTO) is defined quite unambiguously, the term “Entity” is interpreted differently in various contexts.
The most relevant interpretations of the term “Entity”, in my opinion, are the following three:
-
In the context of entity-relationship- and ORM-frameworks – specifically Enterprise Java and Jpa:
“An object that represents persistent data maintained in a database.” -
In the context of “Domain-Driven Design” (by Eric Evans):
“An object defined primarily by its identity, rather than its attributes.” -
In the context of “Clean Architecture” (by Robert C. Martin):
“An object that encapsulates enterprise-wide critical business rules.”
The Jee- and Jpa-community sees entities primarily as objects mapped to
a database table. This point of view is very close to the definition of a DTO – and that’s where much of the confusion probably stems from.
In the context of domain-driven-design, as well as Robert Martins point of view, however, Entities are part of a business domain and thus can and should implement behavior.