Java Persistence layer in regards to Service/Repository layers

Question

I need a solid explanation on three software architecture layers (listed below) in a Java EE environment, that I have taken from multiple contexts. In short, this is what I have gained:

• Service Layer: Contains services behind the front-end with functionality fit for re-use during the software's life cycle
• Persistence Layer: Handles operations behind the front-end, intermediate between the front-end and the Repository layer.
• Repository Layer: Wraps data-handling operations for data creation/retrieval in the back-end.

After panning through multiple articles, I am confused as to where the distinction lies between the Service and Persistence layers - could they overlap or be synonyms of one another? I never hear them mentioned in really the same context.

Are all of these layers always used/easily distinguishable?

Thank you.

Answer 1

The Service layer encapsulates the business logic and computations for the application. The word Service is used to emphasise the point that a business logic layer modeled using Service-oriented design principles can be used by different consumers, such as, a web presentation layer, an API integration layer, remote mobile clients, other services, and so on. Examples of services could be PayrollService, DiscountService, OrderService, etc. This allows business logic to be written once and consumed in multiple places across different technologies, locations and applications.

The Persistence layer is responsible for offering data access operations to the service layer. In order to obey the principle of loose-coupling, the service layer should not worry about how and where data is stored - simply that it can access required data when it needs to. The service layer should simply apply the required business logic to the data, such that the data access code is separate from the business logic code (in any serious enterprise application).

---

Repository is a design pattern commonly used for implementing the persistence layer. Among many other things, it allows the application data to be modeled and managed as a domain model (a way for technical team members and business users to share a common understanding of the business domain). This allows the use of Domain-driven design by ensuring that the technical and non-technical users share a common terminology and technical artifacts mimic their real-world counterparts as closely as possible. The repository pattern is also useful because it allows the service layer to access all (or at least most) data sources through a consistent interface (most frameworks that offer a repository based persistence layer provide the basic CRUD methods on all repositories). Examples of repositories could be OrderRepository, PersonRepository, DepartmentRepository, etc. Martin Fowler's website has an excellent overview of the repository pattern.

That said, repository is not the only way to design and implement the persistence layer - it can be implemented in other ways as well, the simplest being the use of native data access technologies such as JDBC, ODBC, ADO.NET, etc.

---

Now, to answer the question, the Service and Persistence layers should be separate in a properly architected software system to provide loose coupling between the business logic and data access components of the system (if you agree that business logic and data access are two separate concerns). See SOLID principle for a primer on encapsulating individual application concerns as separate components. Any overlap between these two layers would be bad as it will lead to hard coupling, possible code duplication, scattered bugs, code inflexibility, etc.

Repository is a design pattern and one of the possible ways to implement the persistence layer, although there are other ways to implement the persistence layer. The following visual depiction may help:

 -------------------------------                 -------------------------------
|       W e b   l a y e r       |               |        A P I   l a y e r      |
 -------------------------------                 -------------------------------
 -------------------------------------------------------------------------------
|                          S e r v i c e   l a y e r                            |
 -------------------------------------------------------------------------------
 -------------------------------------------------------------------------------
|                      P e r s i s t e n c e   l a y e r                        |
 -------------------------------------------------------------------------------
                                ---------------------------
                               /                          /
                               ---------------------------
                             /                           /
                             ---------------------------
                           /   D a t a   S t o r e s   /
                           ---------------------------