Explaining the concept of the domain-store pattern

We covered the data-access object pattern in the previous section and looked at how this pattern makes an abstraction of the data access logic from the business tier. However, the data-access object pattern is a stateless pattern that does not save states and intelligence inside them. Some problems have a complex relationship between data, and the data persistence needs to be done through an intelligent process. To promote this feature, the data-access object pattern does not attend. This is because DAO shouldn't maintain states, shouldn't contain any intelligent processes, and need only contain a process for saving or updating. To solve this problem, the domain-store pattern was created—a pattern that can add functionalities to DAO.

The domain-store pattern is a pattern that makes the object-model persistence transparent, separating the persistence logic from the object model, making it possible for the application to select the persistence logic according to the object state. Inside this pattern exists a DAO, designed to communicate and manipulate data with the data source, but this DAO is hidden from the application. This pattern is rarely implemented by developers because JPA already works as a domain-store pattern. This is because the JPA implements some intelligent processes to define when and how to save the data and its intelligent processes are oriented by the mapping made on JPA entities. However, when we decide to implement persistence in another type of data source, we may want to implement this pattern and use it in our application. In the following diagram, we can see the domain-store pattern model:

Many developers believe that the DAO is dead after JPA. This is because the JPA works with the domain store pattern and already has an internal DAO. However, to us, the DAO is a good pattern to use on Java EE projects. This is because JPA has a stronger relationship with relational databases, and if we substitute the relational database for another type of data source, we will possibly need to remove the JPA and use another mechanism instead. If all JPA calls are inside DAO, the application will only see DAO, and the JPA implementation will be hidden from the application. This makes the business tier more decoupled from the integration tier and the persistence logic.