I would argue that you may have gone too far. I do not believe that naming is a wasted exercise. In practice, however, I don’t often employ such detailed names.

Consider an Object-Oriented solution where the client of the service knows how to send a message to the service but it does not know the actual receiver of the message and, therefore, the actual logic employed (protected variation). This is similar to the ideas of Policy Enforcement Point and Policy Decision Point. You know that there will be a Policy Enforcement Point intercepting the request. You do not know which policies will be enforced, however. Here, I believe that more generic names should be preferred.

In the FP world, the client may know precisely what the service does as it is the client that furnishes some of this behavior with anonymous functions. The entire behavior is often assembled using function composition and consequently has no name. You could certainly place this composition behind a very specific name but I feel some hesitation.

I am happy that you performed some separation, as opposed to embedding the behavior inline. I am happier that you did not resort to private methods. I simply don’t see the exercise of naming proceeding as far as it did in this article.