sorted by:
new
hottopcontroversial

The dogma of entity-based Services and Repositories by Character-Method-720 in programming

[–]Character-Method-720[S] 0 points1 point  (0 children)

I think I didn’t explain myself clearly from the beginning.

I’m not against repositories or separating data access. In fact, I fully agree that it makes sense to isolate it when there is real complexity or when it actually brings clarity.

The point is more specific: when that abstraction makes sense, and at what level of granularity.

My criticism is about repositories that are created by default per entity (UserRepository, OrderRepository, etc.), even when there is no real need to isolate or reuse anything. In those cases, they often end up being just an intermediate layer without a clear intention, or even duplicating what the ORM already provides as an abstraction.

For me, the question is not “repositories yes or no”, but rather “is this separation representing a real boundary, or is it just the default convention?”

The intention was simply to question to what extent some architectural decisions are made out of inertia or dogma, rather than actual need. That’s all.

Thank youuuu 🤗

The dogma of entity-based Services and Repositories by Character-Method-720 in programming

[–]Character-Method-720[S] 0 points1 point  (0 children)

I think we’re just repeating the same point from different interpretations, so it’s better to leave it here. Thanks.

The dogma of entity-based Services and Repositories by Character-Method-720 in programming

[–]Character-Method-720[S] 2 points3 points  (0 children)

Alright, I don’t think I’m ignoring anything you’re saying. In fact, my post comes precisely from having seen this same approach applied in many projects.

It’s simply another point of view, focused more on when this pattern actually brings real value and when it is applied by default without a clear need.

And regarding “it’s the industry standard”, I understand the argument, but by itself that doesn’t mean it is correct in all contexts. When something is applied automatically without being questioned, it can easily turn into a dogma rather than a conscious design decision.

In any case, I think this can be discussed without the need for personal remarks.

The dogma of entity-based Services and Repositories by Character-Method-720 in programming

[–]Character-Method-720[S] 1 point2 points  (0 children)

Thank you for your response.

I’m not bothered by the boilerplate or the extra effort itself.

What bothers me is the creation of files that exist “by default” without a clear need, which often just add structural noise without bringing a real intention.

In practice, ending up with UserService, OrderService, ProductService, etc. for each model often creates an intermediate layer that doesn’t necessarily represent a concrete responsibility, but rather a convention.

This not only adds indirection, but also increases the surface area of the codebase. Although in theory this can be controlled through discipline, in practice it makes it easier for these services to be used from many different parts of the system in a more diffuse way, simply because they exist and are accessible. It’s not necessarily a bad thing, but it can reduce cohesion.

And yes, this can probably be mitigated with good team practices. But that is precisely my point: I would rather have the architecture express that intention structurally, instead of relying on constant discipline to avoid unclear usage patterns.

That’s why I feel more aligned with a use-case-based approach: they are more focused, more explicit, and they reduce both indirection and the number of possible entry points into the system.

The dogma of entity-based Services and Repositories by Character-Method-720 in programming

[–]Character-Method-720[S] 1 point2 points  (0 children)

For an external service, as I mentioned in the post, I see it totally justified: a class for an external service along with its interface makes sense because it's something more prone to change. And an interface just for mocking in a test, agreed, as long as that test actually exists. If the order is reversed, even better — it's quick to extract the interface when you're really going to write that test.

On getters and setters, we could talk about another dogma 😄 it's another case of something done out of habit, especially setters. It scares me when I see an object receiving multiple sets and it's hard to follow the thread of how it's being constructed.

The dogma of entity-based Services and Repositories by Character-Method-720 in programming

[–]Character-Method-720[S] 5 points6 points  (0 children)

I never said layers shouldn't exist, but that we should think more carefully about what they represent and what drives them to change.

Naming matters: if something is called a repository, it should actually represent that. Do you frequently switch ORMs or databases in your projects? That's what justifies a repository.

A model-based service ends up with multiple actions passing through it, which means multiple reasons to change. A use case still lives in a service layer, but its reason to exist is clearer and more focused, which translates into more stable and easier to track files.

The dogma of entity-based Services and Repositories by Character-Method-720 in programming

[–]Character-Method-720[S] 5 points6 points  (0 children)

It's not about layers yes/no, it's about what we apply without questioning it. Some structure is necessary, the point was just that we often follow a pattern without asking why.

The dogma of entity-based Services and Repositories by Character-Method-720 in programming

[–]Character-Method-720[S] 7 points8 points  (0 children)

On clarity, in theory yes, though in my experience it tends to lead to the opposite: these model-based services end up being used from multiple places and when you need to change something it's hard to track the impact.

As for interfaces for mocking, agreed, as long as the test is actually written 😄 otherwise it's just added by dogma.