When does it make sense to use "regular" classes instead of services?

Question

symfony

Recently I started to get acquainted with fw Symfony.
As I understand it, most of the code in the project lives in services - global classes that load each other as dependencies.
There is a task:
To bypass the table in a DB and for each extracted line to execute some work.
Having written the service, I discovered that it contains:
a constructor where dependencies are placed (two factories and an EntityManager),
one public method that takes two parameters (for now) Entity from the base and one more external object.
And a bunch of private methods in which these two parameters travel. (It is this moment with a bunch of methods with almost the same signature that confuses me. However, I cannot add these parameters to the constructor. So they are not static, but are taken from the base and I need to execute the method)
In a normal situation, I would make a class that takes the two necessary for it parameter to the constructor, dependencies are pulled up by the singleton, and private methods take parameters from properties.
But this does not fit the framework paradigm.
I see this option:
Make a service - a factory that will generate a new object described in the paragraph above based on these two dynamic parameters. And at the same time, it will import all dependencies into this object.
How correct is this option relative to the first one?
Confused by the number of parameters for this new object's constructor (both dependencies and parameters).
The question was raised because I want to log each work on the data separately. And this means that I need to pass one more parameter to the original service - the logger. And drag it along private methods.
Or just add the setLogger method to the object described in the second option.
Thank you.

Answer 1

Normal code at first glance.
Well, you can call getBySource() in the public method, then you can replace two parameters with one. Well, this is if there is absolutely nothing to do.
Well, the logger in your code should be passed to the constructor and stored in the property

Answer 2

But this does not fit the framework paradigm.

This violates the principles of dependency inversion and not the "framework paradigm". In fact, such things break the principles of OOP and all the best-practices that all sorts of java developers (and not only java) have thought up over the past 20 years.
Services are "ordinary" classes. It’s just that a separate component is responsible for creating these classes, it alone knows how to create and resolve dependencies so that you don’t have to do it by hand. Another question is that if you take some kind of PHP-DI, then it makes it a little more convenient (due to autoconfiguration based on namespaces).
Further... the fact that you have both a logger and some two factories and an EntityManager injected into one class leads me to the idea that no matter what you do there, you do not even try to comply with the single responsibility principle . Maybe I'm wrong and all this is really needed ... Alas, you did not provide details.
In a word ... all this is not Symfony-specific stuff, it's classic OOP and nothing more. If you describe the task in a little more detail (at least at the level of interfaces), it will already be possible to suggest something specific. So far, I don't see anything wrong with a bunch of private methods. The main thing is that the interface is clean. Something on the level

interface EntityProcessor
{
    public function process(Entity $entity);
}