In previous chapters, you have seen that one of Spring's goals is to allow you to develop applications by following one of the OOPs principles of coding to interfaces. Any enterprise application needs to read data and write data to any kind of database, and to meet this requirement, we have to write the persistence logic. Spring allows you to avoid the scattering of persistence logic across all the modules in your application. For this, we can create a different component for data access and persistence logic, and this component is known as a data access object (DAO). Let's see, in the following diagram, the best approach to create modules in layered applications:

As you can see in the preceding diagram, for a better approach, many enterprise applications consist of the following three logical layers:

• The service layer (or application layer): This layer of the application exposes high-level application functions like use-cases and business logic. All application services are defined here.
• The data access layer: This layer of the application defines an interface to the application's data repository (such as a Relational or NoSQL database). This layer has the classes and interfaces which have the data-access logic's data persisting in the application.
• The infrastructure layer: This layer of the application exposes low-level services to the other layers, such as configuring DataSource by using the database URL, user credentials, and so on. Such configuration comes under this layer.

In the previous figure, you can see that the Service Layer collaborates with the Data Access Layer. To avoid coupling between the application logic and data-access logic, we should expose their functionality through interfaces, as interfaces promote decoupling between the collaborating components. If we use the data-access logic by implementing interfaces, we can configure any particular data-access strategy to the application without making any changes in the application logic in the Service Layer. The following diagram shows the proper approach to designing our data-access layer:

As shown in the preceding figure, your application service objects, that is, TransferService, don't handle their own data access. Instead, they delegate data access to the repositories. The repository's interface, that is, AccountRepository in your application, keeps it loosely coupled to the service object. You could configure any variant of the implementations-either the Jpa implementation of AccountRepository (JpaAccountRepository), or the Jdbc implementation of AccountRepository (JdbcAccountRepository).

Spring not only provides loose coupling between the application components working at the different layers in the layered architecture, but also helps to manage the resources in the enterprise layered architecture application. Let's see how Spring manages the resources, and what design pattern is using by Spring to solve the resource management problem.