When I can't find a good name for a class, it's almost never a vocabulary problem. It's a design problem. The thing I'm trying to name does too much, or it sits at the wrong level of abstraction, or it represents two concepts pretending to be one.

A good name is as short as it can be, as specific as it can be, and boring: RsvpAllowlist, NameMatch, or even StripEmptyValuesFromLogs. You read the name and you know what it does. No surprises.

The name should come from the domain, not from the pattern. If the best you can come up with is DataProcessor or ServiceManager or Helper, stop. And watch out for anything ending in -or. A Calculator is better than a Processor, but PremiumCalculation is better than both. The name should tell you what, not how.

Sepehr Namdar says it better than I can in 90 seconds: watch here.