(Mainly C#) Naming of different parts in a project

Im currently working in a legacy system which I am trying to implement some kind of structure to.
Since the system is more or less a huge monolit with very little ioc that is one of the things Im trying to solve.
And whith these changes I hope to make the system testable which is very hard in its current state.

Since the code were'nt written with testing in mind Ive realized that I have to break big chunks of the code into services, methods etc. This is where my real question comes in.

When you do extract code, how do you name or classify the new files ? Sure in a perfect world it would be that hard but for example:

Ive got a controller. The controller builds up a view-model and returns it to the view. All of that logic is today in the controller itself.

My first idea was to extract the view-model building into a new file, like a service so I can moq it if needed. That service would be split up into alot of methods that handle each and every part of the view-model.
Then I figured that if I put all of those methods in the same file I would have to make them private since the controller doesnt have a need to know about those methods.
Setting them as private makes the code, once again, hard to test.
My thought then were to break out the logic in those into another file so I can have them all public and by doing that my code would be easy to test.

• Am I heading in the right direction ?
• How far should you go with all this?
• What would I call those new files ?
• Should they all be services ? Handlers ? Helpers ?
• Maybe they should mostly be services that call other services?

Sorry for the long question but I felt I had to explain it in as much detail as I could since Im pretty sure there may be alot more than one solution to this.

Thanks

/Jhonny