What should be in the infrastructure layer in a multilayer application?

Question

PHP

I read a lot about different layers and I seem to understand everything. But I did not understand the essence of the infrastructure layer.
It seemed to me that I already understood what it means, at first I thought that there are classes that are responsible for functionality that is not part of the business logic, but is needed for the application to work.
I also had a theory that these are classes that involve third-party libraries or components from frameworks.
But I was stunned by an example from the book 'Domain-Driven Design in PHP', here:

namespace Ddd\Auth\Domain\Model;

interface SignUp {
    public function execute($aUsername, $aPassword);
}

The bottom line is that implementations of this interface must have different password hashing mechanisms. There are two implementations of this interface in the book that are in the infrastructure layer, the first is the DefaultHashingSignUp class, which uses PHP's built-in password_verify() function. The second implementation is the Md5HashingSignUp class, which uses PHP's built-in md5() function and "salt".
The book says these classes are "Infrastructure Services".
So, I don’t understand why they are in the infrastructure layer, they also contain business logic. Yes, there are methods built into PHP, but they can't be the cause, can they? Various Entites from the Domain layer can also use built-in functions, but because of this, these Entities are not in the infrastructure layer because of this.
So why not leave DefaultHashingSignUp and Md5HashingSignUp on the Domain layer? Why is dependency inversion needed in this case? I seem to understand what the essence of dependency inversion is, its essence is that implementations must adapt to the interface that is declared in the Domain layer, this kind of shows that the Domain layer is the center of the application, that it does not depend on other layers. But is the inversion appropriate here? Aren't these implementations part of the Domain layer? Is it necessary to remove them in another layer? Why can't they stay in the Domain layer?
Maybe they are in infrastructure. layer because there are several implementations? And if one implementation was enough, that is, the usual SignUp class would be enough, and the strategy pattern would be used in it to change the hashing. Then it would be possible to leave it in the Domain layer? (It seems to me that I gave birth to some kind of heresy)
I (seem to) understand why dependency inversion is needed in the case of the Persistense layer, the classes from this layer are not part of the business logic. The persistence layer is like a tool, because without the ability to save data it is difficult to implement an application. That is the same tool as a programming language.
In short, please, I belittle, otherwise I'm stupid, bombed and tired. It seems to me that the answer is obvious, but I do not always notice the obvious. There is too much going on in my head and I can't put it all together.

Answer 1

Everything that is not important for business logic should be outside the domain layer.
Is it important for a business how the password hash will be built? (Undoubtedly, it depends on the business, but in 90% of cases it does not).
Ask a domain expert or at least a manager about this.
They may not even know what a "hash" is in principle.
And the interface lies in the domain, because you need to somehow connect this "doesn't matter" with "necessary".
Even if there was only one implementation, it was taken out in the example anyway.
Whether it is possible to put in the domain? You are building a system. If you want, put it in the domain layer, if you want, take it out to the microservice. If you want, write in PHP, or Go, or C++.
As you decide, do so.
It is more correct to abstract the domain from everything superfluous. Everything that does not concern the subject area. But only sometimes (almost always) this cannot be done adequately and the next June will definitely do something wrong.
Plus, you can choke yourself with abstractions, so you can’t figure out what to use later.
There are things that will change regardless of your subject area:
package updates, security vulnerabilities when using something, new fast implementations of any modules. In this case, your business layer should not be subject to change. But he must clearly know that if he calls the implementation of this interface, he will get the result. That's all you have to guarantee on the business layer.