Domain-Driven Design also defines so-called entities. As the name already suggests, an entity represents a business domain entity in essence. These entities are identifiable instances of a concept deeply contained in the specific domain. Users, articles, and cars are examples of such entities. It is important to the domain that the entities can be separately identified. It makes a difference whether user John Doe or user John Smith invoked some use case. This aspect distinguishes entities from value objects.

Entities, as well as other model objects, are implemented as plain Java classes. For the sole business domain to function, there is no framework support required. Ideally, entities already encapsulate certain business logic that is self-contained within the entity type. That means that we will not only model simple POJOs with properties plus getter and setter methods but also business relevant methods that operate on that entity. Integrating business logic directly at the core of the business entities increases cohesion, understanding, and embraces the single responsibility principle.

Typically, entities as well as other domain model types, are persisted in a database. Java EE does support object-relational mapping with JPA which is used to persist and retrieve objects and object hierarchies. In fact, the JPA annotation used to declare entity types is called @Entity. In a later sub-chapter, we will see in detail how JPA supports to persist domain model types with minimal disruption on the model classes.