The Java Persistence API (JPA) is used to integrate relational database systems into enterprise applications. Compared to outdated approaches of the J2EE era, JPA integrates well with domain models built after the concepts of Domain-Driven Design. Persisting entities does not introduce much overhead and does not set many constraints on the model. This enables constructing the domain model first, focusing on business aspects, and integrating the persistence layer afterwards.

Persistence is integrated into the domain as a necessary part of handling the business use case. Depending on the complexity of use cases, the persistence functionality is invoked either in dedicated controls or directly in the boundary. Domain-Driven Design defines the concept of repositories which, as mentioned before, matches the responsibilities of JPA's entity manager well. The entity manager is used to obtain, manage, and persist entities and to perform queries. Its interface was abstracted with the intention to be used in a general way.

In the J2EE era, the data access object (DAO) pattern was used heavily. The motivation behind this pattern was to abstract and encapsulate functionality to access data. This includes the type of the accessed storage system, such as RDBMSs, object-oriented databases, LDAP systems, or files. Whereas the reasoning certainly makes sense, following the pattern in times of Java EE is not required for the majority of use cases.

Most enterprise applications use relational databases that support both SQL and JDBC. JPA already abstracts RDBMS systems so that engineers usually don't deal with vendor specifics. Changing the nature of the used storage system to something other than a RDBMS will impact the application's code anyway. Mapping domain entity types into storage does not require the use of transfer objects anymore, since JPA integrates well into domain models. Directly mapping domain entity types is a productive approach to integrate persistence without much overhead. For straightforward use cases, such as persisting and retrieving entities, a DAO approach is therefore not required. However, for complex database queries involved, it does make sense to encapsulate that functionality into separate controls. These repositories then contain the whole persistence for the specific entity types. It is advisable though to start with a straightforward approach and only refactor the persistence into a single point of responsibility if the complexity increases.

Boundaries or controls, respectively, obtain an entity manager to manage the persistence of entities. The following shows how to integrate an entity manager into a boundary:

import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;

@Stateless
public class PersonAdministration {

    @PersistenceContext
    EntityManager entityManager;

    public void createPerson(Person person) {
        entityManager.persist(person);
    }

    public void updateAddress(long personId, Address newAddress) {
        Person person = entityManager.find(Person.class, personId);

        if (person == null)
            throw new IllegalArgumentException("Could not find person with ID " + personId);

        person.setAddress(newAddress);
    }
}

The persist() operation on creating new persons makes the person a managed entity. It will be added into the database once the transaction commits and can be obtained later using its assigned ID. The updateAddress() method showcases this. A person entity is retrieved using its ID into a managed entity. All changes in the entity; for example, changing its address will be synchronized into the database at transaction commit time.