> Why would you shove unrelated functionality into the same service?
Because you notice that Broadcast-Service happens to already know some other important stuff about all the enregistered clients. And perhaps answering queries about that or naming ends up becoming its most important job... even though it was originally just a simple broadcast service.
Then, later, you end up not even using the broadcast functionality.
Code drifts and changes. Top level names are more likely to be lies than variable or function names, because the latter are easy to change.
> Because you notice that Broadcast-Service happens to already know some other important stuff about all the enregistered clients.
Looks like you are trying to get a complete separation of concerns. That's a good practice when modularizing code, but it's not unambiguously good for services, because composing services come with added cost.
On practice that means that if those pieces of information are really important, there will probably exist many services that read them, and trying to reduce that to a single one will break many good qualities your software has elsewhere. Your service having a clear purpose is one of those qualities.
“The name doesn’t reflect its function anymore” is not a good case for “let’s name it some random thing”, and certainly not a good case for “let’s arbitrarily give descriptive names for some resources over others”
It's very difficult to change service names, given that you have a large population of people conditioned to say the name and lots of documentation artifacts, other code, etc.
"Broadcast message service" is, as the author points out, way too generic and also too long to be used freely. "Scattershot" rolls off the tongue and won't be completely wrong if functionality changes. And hopefully we have a small enough quorum of services that we don't drown in jargon.
Because you notice that Broadcast-Service happens to already know some other important stuff about all the enregistered clients. And perhaps answering queries about that or naming ends up becoming its most important job... even though it was originally just a simple broadcast service.
Then, later, you end up not even using the broadcast functionality.
Code drifts and changes. Top level names are more likely to be lies than variable or function names, because the latter are easy to change.