Domain-Driven Design (DDD)

Create an Aggregate Root entity that exposes domain methods for all state changes, and access child entities only through the root. Define one repository interface per aggregate root in the domain layer, implemented by a JPA adapter in the infrastructure layer.

An entity has an identity (id) that persists across its lifecycle, while a value object is defined entirely by its values and has no identity. Value objects should be immutable, override equals() and hashCode(), and are best implemented as Java records.

No, domain entities should not import JPA, Spring, or Hibernate annotations. Keep a separate JPA entity in the infrastructure layer and use a mapper plus repository adapter to convert between the JPA entity and the domain entity.

Use a domain service only when business logic spans two or more aggregates and does not naturally belong to any single one. Logic tied to one entity, such as checking low stock on a product, belongs inside that entity as a domain method.

An anemic model reduces entities to data holders with getters and setters, pushing all business logic into services. This scatters rules across the codebase and breaks encapsulation; DDD instead places behavior inside entities through meaningful domain methods.