I have case. I have domain model of User. Let's say that the user can change his name only if he has a specific tier of subscription. Information about active subscriptions is retrieved from a completely separate service that is accessible via IBillingService.
Should this IBillingService be used in CommandHandler and check if user can change name there? Or should it be injected in User's domain model and check in "ChangeName(string newName) method?
In short. Where to handle business logic if parts of this logic come from external services?
As far as I know, there isn't an authoritative answer to this. Domain Driven Design is primarily a pattern language, rather than a collection of design constraints, and so the answer tends to be "it depends".
That said: as soon as you start coupling your code to capabilities deployed somewhere else, you introduce potential failure modes that are not part of the "ubiquitous language" of your idealized problem domain.
If you are handling those failure modes explicitly, then you are going to have a bunch of "plumbing" code.
Now, consider the motivation for "repositories"; part of the point is to physically separate the logic that we need for doing persistence things from the logic of the domain itself.
If that's a valid motivation for repositories, it's likely a valid motivation for other forms of plumbing.
A potentially useful way of thinking about things: the domain model needs information, but typically doesn't get coupled tightly to the details of where that information comes from.
Following that logic, it can make sense to fetch information in the application code, and then pass that information to the domain code where all of the branching would happen.
So in your example, your application code would invoke the billing service to get information about the user's active subscriptions, and then the domain code would use that information to determine if a name change is permitted.
(I'm eliding some concerns about whether the policies belong in this service or that one: do we ask for all subscriptions, or active subscriptions, or active subscriptions at the appropriate tier, or.... There's a division of responsibility problem, but the details aren't too important -- there is some information over there, and we want a copy of that information here.)
A case where things can get clumsy: when fetching the information from the billing service is expensive, and not always necessary. In that case, you might want to let your local domain logic decide whether or not to make that call.
And in that case, you need to make some choices about whether you pass the capability of invoking the billing service to your domain model (typically by wrapping the billing service in a Domain Service, and then passing a handle to that service to the domain code) or by introducing a protocol so that the domain code can ask the application code to invoke the domain service, and pass in the answer.
It's all trade offs. The right way to do it is going to depend strongly on the "what we want".