It sounds like this idea makes some sense in the context of having made a large number of mistakes already, but the real answer is, don't let it get that bad. T

It sounds like this idea makes some sense in the context of having made a large number of mistakes already, but the real answer is, don't let it get that bad. The author strikes me as having worked only at companies that are so dysfunctional that they have never seen what a functioning team looks like. It starts going downhill here: > Trouble is, names are hard to change. Uh, why? They shouldn't be. It should be a find/replace on text, with tests to catch any issues. The essay later goes on to talk about people using the name... but that doesn't matter, because the code is the self-checking source of truth. Additionally, name changes should be rare if you did your job right the first time. > A well-factored service will generally have a tight set of responsibilities which make sense together, and this makes a descriptive name very appealing. No. Wrong. A well-factored service has ONE responsibility. Period. Not "responsibilities", "responsibility". This is what I mean when I say that a name change should be rare if you did your job right the first time. If a service has multiple responsibilities, you don't need to change the name, because you aren't adding or removing responsibilities. If you no longer need what the service does, the service can stop existing. And if you need something new, you create a new service. And yes, sometimes performance means that you want to chunk stuff together, and strictly passing every different task over the network bus will cause your application to grind to a halt. That's more a criticism of the weird assumption that passing things over the network is necessary for encapsulation than of the single-responsibility principle, however. If your services are tightly coupled to separate network requests, you're going to experience pain no matter what you do. One of the first things a microservices architecture should do is abstract away the network so that from the caller's perspective, they don't know whether calling a service is making a network request or calling a library. > I don't want to be the one to advocate for delaying features so we can rename broadcast-service to broadcast-and-new-responsibility-service. That's going to be an unpleasant conversation with your product manager, for good reason: Because this never should have happened, and it's a waste of time to change the name. Agreed, because a) broadcast-service is a pretty vague name and b) new-responsibility should be its own new-responsibility-service.