The data layer, also called the persistence layer, stores domain-model state in durable storage and retrieves it when the application needs it. It sits between the business layer and the external database: business logic works with domain entities, while persistence components preserve those entities’ state. section 3.1.1
Use the layered-architecture figure to place the persistence layer beneath domain-model operations and above the database. section 3.1.1
A well-separated data layer keeps responsibilities distinct:
- The presentation layer renders domain-entity state for users. section 3.2.1
- The business layer executes rules and calculations against domain entities. section 3.1.1
- The persistence layer loads entities from and stores them in the database. section 3.2.1
- The database holds the system state for the long term, usually through a schema and possibly stored procedures. section 3.1.1
Separating persistence concerns prevents domain logic from depending on a particular container, runtime environment, or service mock. A domain method such as Item#calculateTotalPrice() can therefore run against in-memory state in a unit test, while database loading and storing remain persistence or integration concerns. section 3.2.1 section 10.1
Persistence is transparent when entity classes do not need to know whether their state is temporary or durable. JPA defines the entity class as the primary programming artifact; Hibernate provides an ORM implementation, and metadata such as annotations or XML lets the runtime apply persistence and transaction behavior generically. section 3.2.1
At runtime, the application interacts with Jakarta Persistence to load or store state. A persistence context remembers changes within a unit of work, while entity states and managed scope determine how an instance participates in that lifecycle. section 10.1





