I see services in DDD as result of Dependency Inversion.
If you were to use "plain" dependencies, then your domain code would call database to save or query an entity, or factory, that creates an entity, that are tied to database or external service or some kind of other infrastructure code.
But that is not how domain code should be. Domain code should not depend on infrastructure code. As this dependency makes it harder to test and, possibly, reuse. Which is why you invert that dependency. You make infrastructure code depend on the domain code. And to do that, you need to introduce an abstraction. An abstraction that defines what behavior the domain code expects to be implemented by the infrastructure.
And services in DDD are that abstraction. In majority of cases, for domain code, those services should be plain interfaces. And the implementation should be in the infrastructure code, which has dependency on those interfaces.