About layered architecture and the persistence layer

Question

I’m pretty sure I’ve made some wrong assumptions in my questions so bear that in mind.

At some point, the methods inside objects that are part of the persistence layer will be called/accessed for say… retrieve some data from the persistence mechanism ( DB, noSQL, txt file, external API etc… ), where this calling is going to take place, if the persistence layer is at the bottom of the dependency chain? (Lowest policy, through “transitive dependency” depends on almost everything) Is it going to take place in the highest level policy layer (entity, business or domain layer)? or in the application layer?

I imagine the interaction with the persistence layer through a set of method calls that are named accordingly to each and every operation with the persistence mechanism, like: getUserID(x), getPostID(x) and this method to return either an object that represents a row (Active Record?) or the data as a Data Transfer Object … But as the application will eventually grow larger I, imagine the boundary interface between the application and persistence layers to grow as well, polluted with methods that once implemented represents all the operations available on the persistence mechanism, like the examples from above. Isn’t this a violation of the ISP?

Answer 1

I guess what you are looking for is the repository pattern. The idea is to implement any persistence-related methods not inside the domain object, or some god-class-like "datastore" object, but inside repository objects, which are structured in a 1:1 manner to your domain entities. Repositories can be seen as a layer between your domain objects and the persistence layer.

So for example, if you have a User object, there is also a repository object UserRepo which contains an abstraction for the usual CRUD methods, or maybe other persistence-related operations for Userobjects. UserRepo maybe just an interface, so a specific persistence-aware implementation ("UserRepoImpl") can be mocked out for testing purposes by something like a UserRepoMock.

So what does that mean for your questions?

But as the application will eventually grow larger I, imagine the boundary interface between the application and persistence layers to grow as well, polluted with methods that once implemented represents all the operations available on the persistence mechanism.

Yes, when your application grows, there will be more domain entities, hence the repository layer will grow. But there is no "pollution" - the repo layer is exactly where all persistence operations belong.

Isn’t this a violation of the ISP?

Any part of the system which needs access to the persistence mechanics does only need to depend on the repo interfaces of the domain entities it deals with. It does not need to depend on repos for other domain entities. So no, the ISP is not violated, quite the opposite.

[do] I have to inject an persistence-related object into a domain object, right?

If the domain object contains methods which require to access the persistence layer (like User.getAllPosts()), then one has to inject a repository object into it at construction time, or just pass it at the call (User.getAllPosts(postRepository)).

Is that an violation on the The Dependency Rule from Clean Architecture?

No, since the domain objects are only using interfaces, there is no direct dependency from the domain layer to the repository layer. In the example above, the User object would depend on the interface PostRepo, but not on PostRepoImpl. See also Clean Architecture, the section about "Crossing boundaries".

Answer 2

It depends on how things are structured. It's possible to have a persistence layer with 1k methods and have a client that uses them all. It may not use them all equally, but that isn't relevant. That is just fine as far as the ISP is concerned. Generally as applications grow, interfaces are split into multiple interfaces based on different business objects so you don't have super huge interfaces and files.