Why have service classes? (Service Layer Model)

Question

tl;dr - What are the advantages of having handler and service methods separate housed in separate classes, rather than joined in a single class.

Background

Salesforce and others reference using Service classes as part of a best practice breakdown of class and trigger architecture. (Trailhead example, stackexchange example, third party article example)

The premise seems to be that Triggers handle "when" the automation launches, a handler class handles "what" launches, and the service class handles "how" the automation works. I understand the basic ideas behind dividing functionality into distinct areas, but the separation of a handler and service class seems a bit excessive to me.

A practice I have been doing for a little while is simply having the "stoplight" considerations at the top of a handler class (aka, what fires when), and then below the stoplight code is a comment in the code stating the service methods are below, followed by the various service methods. The advantage I see in this model is that I don't have to have multiple files open, and can easily do text searches across my single file to locate code.

Question

Since there is so much written about the service layer model, I imagine there is something I'm missing here, and was wondering if anyone could explain the clear advantages of having handler and service methods separate, rather than joined in a single class.

Answer 1

The answer you linked from Adrian outlines the advantages really well already. In terms of your specific concerns in this question - the big thing that sticks out to me is scaling your product/customizations.

the separation of a handler and service class seems a bit excessive to me.

I think that could be a reasonable conclusion depending on the context of the org. There's orgs with very minimal code with no future plans of investing heavily in that area that it would seem excessive

The advantage I see in this model is that I don't have to have multiple files open, and can easily do text searches across my single file to locate code.

Going off your personal listed advantages of not following the approach - think of the following questions:

1. What stops you from putting all your code into the trigger? One file, one place to search
2. What happens to your one file when your org has 5,000 lines of code? Or 50,000 lines?
3. Why is this style you've developed working for you right now? Will it work in the future?
4. What if you had a team of 5 developers and all had to work on the same file because everything is in that file? Compare that with if logic/features were separated out?
5. If you had to separate out your one file with all methods after the fact - would it be easy? Would it be hard - why or why not?

Like most guidelines, the negative consequences of not following certain principles doesn't always appear in the short-term. It's a delayed pain when you ramp up and exponentially increase the features/customizations of your product/org. Pivoting or refactoring can be painful whereas starting from the beginning with good principles can alleviate a lot of future issues.

What those principles/guidelines are depend on your team makeup, their experience, knowledge level, and personal opinion as well. SOLID, as an example, focuses on making software designs more understandable, flexible, and maintainable.

I'd argue that the model in this question tries to aim for exactly that.