That's definitely a possible failure mode, but I think it's preferable to having DataProcessingWorker, IngestService, ProcessingService, DataLoader, etc. Because, you eventually end up with all of these names and it's just as hard to guess what happens where as if they were named after fruits.
At least for me having too many names that are nearly semantically identical is worse than names that are a little (or even a lot) weird. We stare at names all day and if everything is named `YourCompanyNameMessageDataProcessingService` searches get annoying and it's easy for your eyes to start to glaze over.
If you name stuff like, say, Shucker, you have to ask "wait, wtf is the Shucker service?" Someone explains "It unwraps the GRPC messages and puts the contents on a queue. It's like shucking an oyster I guess? Yeah, we know it's a dumb name." But now you have a unique handle that's not likely to collide with other services.
If you can find a straight laced informative descriptive name that's unlikely to collide in the future that's great. But I'd take a funky name that immediately makes sense once you explain it (reference/pun/acronym whatever) over some 2010s java-class-name-looking beige blob of text any day.
Give me unique and memorable over generic-looking-with-the-merest-bit-of-information.
Used to work at a place where every repo, every service, etc was all CompanyShortNameThingDoerServiceRequester and similar, surprisingly unhelpful. I don’t want the 100th CompanyDataIngesterService because they all blur into one.
At least if someone goes “oh yeah the Oyster service will give that to you” we know precisely which one we mean.
In my personal experience, libraries/code that is widely applicable is what benefits from having a great weird fun name. No one wants to deal with a one off service you decided to name Hecate with no reason or broader appeal.
At least for me having too many names that are nearly semantically identical is worse than names that are a little (or even a lot) weird. We stare at names all day and if everything is named `YourCompanyNameMessageDataProcessingService` searches get annoying and it's easy for your eyes to start to glaze over.
If you name stuff like, say, Shucker, you have to ask "wait, wtf is the Shucker service?" Someone explains "It unwraps the GRPC messages and puts the contents on a queue. It's like shucking an oyster I guess? Yeah, we know it's a dumb name." But now you have a unique handle that's not likely to collide with other services.
If you can find a straight laced informative descriptive name that's unlikely to collide in the future that's great. But I'd take a funky name that immediately makes sense once you explain it (reference/pun/acronym whatever) over some 2010s java-class-name-looking beige blob of text any day.