Hacker News Reader

Comment by jt2190 | Hacker News Reader

It would help a lot if you would clarify what you mean by “service object”. In my experience a single method on a service object would define a transaction. Is that what you mean by “service object”?

View on HN

I think service is an overloaded term. It's so generic that you can probably attach dozens of meanings to it, but here's two: One interpretation is a piece of code that doesn't neatly fit in one domain object (domain service). The other is a piece of code grabbing stuff from the db, orchestrating some domain methods, maybe wrapping it in a transaction, and exposing all that as an endpoint (application service). I think one of you has one in mind and the other the other.

At my last project, they did "service oriented development" and everything was either a service, a viewmodel or a test. For example aLogService, a ValidationService, or an AggregationService.

> I think one of you has one in mind and the other the other.

This is very possible.

Along the lines of what OP is talking about, part of the problem is that Rails has no service objects, so I have seen a handful of different ideas of what they mean (probably no more than 10).

The one I've seen he most is stuff like `UserRegistrationService` or the like. These things can end up getting scattered and in general, I would rather just talk to the business object, ie, `User.register` which can delegate to a more complex private object handling it. It's basically "inverting" things. The win here is that things are more discoverable (You can look at the user object and see a list of everything it does) and more importantly draws better boundaries. This way the web layer only has to know about `User` instead of `RegisterUserService` and `DeleteUserService` etc.

Again, services can work and aren't inherently bad, but plain MVC can certainly also work.

I feel like the same people that like UserRegistrationService will argue that database table names should be plural because it reads better, which is wrong for similar reasons.

I don’t really follow. My focus wasn’t on the naming but the location of responsibilities.

I understood. Perhaps my mental connection was somewhat flimsy though. I was trying to make a tongue-in-cheek joke about how whenever I work on a database that has tables with overloaded responsibilities (poor normalization) instead of proper foreign keys they often also coincidentally have poor, plural names. Whenever I encounter such a thing, I think about the story of how it became that way. Usually part of the story includes a developer looking for a place to stick some logic and deciding an arbitrary place seems good enough because it’s a bit vague.

How are plural names linked to those things, though? I have a low-care level for naming conventions so long as there are conventions. Many successful frameworks use plural tables names. Though I agree singular probably makes a little more sense, especially since it eliminates the need for inflection code.

Your UserRegistrationService(s) is/are also prone to be overloaded. You don’t think of that as part of a naming convention? Would you argue that’s more about architecture? I was simultaneously agreeing with you and adding that this other minor organizational annoyance I have adds to the pile. Apologies if that seems low value.

Reply on news.ycombinator.com