Onion Architecture - Repository Vs Service?

Question

I am learning the well-known Onion Architecture from Jeffrey Palermo. Not specific to this pattern, but I cannot see clearly the separation between repositories and domain s

Answer 1

See the relation between services and repositories on Services in Domain-Driven Design (DDD) by Lev Gorodinski with updates from Vaughn Vernon emphasizing the Hexagonal Architecture style:

An application service has an important and distinguishing role - it provides a hosting environment for the execution of domain logic. As such, it is a convenient point to inject various gateways such as a repository or wrappers for external services.

A service is part of the Application Core as one can see graphically depicted by Onion Architecture or Microservices Patterns by Chris Richardson page 148 in the context of the Hexagonal Architecture.

A repository implementation on the other hand is just an adapter, something that is able to translate the application's messages to a storage system (which could be anything: database, files, etc). See also Interface Adapters section from The Clean Architecture (talking about Interface Adapters layer):

If the database is a SQL database, then all the SQL should be restricted to this layer ...

Search for "repository adapter" at Hexagonal Architecture section Stage 3: (FIT or UI) App mock database talking about the repository implementation viewed as an adapter.

A repository interface on the other hand is part of the Application Core:

• check Onion Architecture:

The first layer around the Domain Model is typically where we would find interfaces that provide object saving and retrieving behavior, called repository interfaces.

• see also page 159 from Microservices Patterns by Chris Richardson in the context of the Hexagonal Architecture

According to Eric Evans Domain-Driven Design:

When a significant process or transformation in the domain is not a natural responsibility of an ENTITY or VALUE OBJECT, add an operation to the model as standalone interface declared as a SERVICE. Define the interface in terms of the language of the model and make sure the operation name is part of the UBIQUITOUS LANGUAGE. Make the SERVICE stateless.

So, a service is just something that contains business logic.

My conclusion: a service is a business logic building block; a repository is just an adapter providing access for the business logic to a storage system. One could mock the adapter to test the business logic in isolation or one could create additional repository adapters to provide more storage options for the application (e.g. file adapter, no-sql database adapter, etc).

About GetAllProductsByCategoryId or GetAllXXXBySomeCriteriaYYY

The repository methods should denote their intention so their naming could be very expressive; while those methods contain only the logic to communicate with the storage system they are fine. Based on the fact that the method naming might be very meaningful some frameworks (e.g. Spring Data) are able to create/generate the implementation for those methods and there's nothing wrong/odd there. On the other hand one might want to optimize/reduce the number of repository methods in various ways like having them accept a complex criteria object or a criteria list instead of having a method for each combination of those criteria, but this doesn't change the role of the repository (implementation) which is still an adapter.

About "is it the role of repository to load the complete hierarchy?"

By now the role of the repository (implementation) should be clear: is to convey the application's messages/requests intended for the storage system. The message/request could be e.g. "give me the Person identified by 123" or "give me a list of Person conform to some criteria" or "give me a complete hierarchy conform to some criteria" as long as the message/request can be translated to the storage system as such. Some storage systems are not able, for example, to give/return a hierarchy object so one should create a service to construct the hierarchy object; other storage systems are able to give/return a hierarchy object but of a type specific to their API/driver so the repository (implementation) should convert it to a DTO which might be further processed by a service in order to construct the business hierarchy object. Remember: a repository (implementation) is just an adapter which should be possible to mock (for testing purposes).

SIDE NOTE

Note also that there could be more types of services: application services and domain services - see them depicted at Onion Architecture but better explained at Services in Domain-Driven Design (DDD) by Lev Gorodinski where one should check for:

The differences between a domain service and an application services are subtle but critical