I can't give you a concrete answer. But, I can give you two things to consider:

Firstly, a domain that "knows" about persistence, at least in a vague sense, isn't necessarily bad.

If domain entities are largely one-to-one with your database tables, you could be following an Active Record pattern. And that's OK. It's simple, and done right -- very few lines of code. (Both very good for maintenance!)

If you're using a repository pattern, which is typical of DDD, it's still OK for the domain to work with repositories. You just ideally want to inject those repositories into the domain. (I might argue locating repo's is also OK.)

An Order in your domain might be constructed with an ILineItemRepo and invoke repo.GetByOrder(this) - and that's OK. It might even need to know, as you suggested, about it's own repository to enforce certain constraints.

Perfectly fine.

Secondly, the domain only needs to know about "core" business rules.

In other words, the domain ideally contains all the rules, and only those rules, that would apply to any application using those entities in your business.

You can certainly stretch this either to fit your team's needs, because your little domain library probably isn't used across the organization. But, I've found it to be a good guiding principle -- especially as other groups in your organization ask for endpoints into your application.

Each client (and endpoint) can have certain rules or special steps that need to be done. But, only those rules that would apply to all possible endpoints belong in your domain.

Everything that seems to apply to a single client's service or "application" belongs in that particular client's service or application ...

I can't give you a concrete answer. But, I can give you two things to consider:

Firstly, a domain that "knows" about persistence, at least in a vague sense, isn't necessarily bad.

If domain entities are largely one-to-one with your database tables, you could be following an Active Record pattern. And that's OK. It's simple, and done right -- very few lines of code. (Both very good for maintenance!)

If you're using a repository pattern, which is typical of DDD, it's still OK for the domain to work with repositories. You just ideally want to inject those repositories into the domain. (I might argue locating repo's is also OK.)

An Order in your domain might be constructed with an ILineItemRepo and invoke repo.GetByOrder(this) - and that's OK. It might even need to know, as you suggested, about it's own repository to enforce certain constraints.

Perfectly fine.

This isn't at all incompatible with a configuration layer deciding how repositories are ultimately handled. Even the Active Record pattern permits this, if done right. Your domain is allowed to know it's pulling objects into and out of something -- it just shouldn't usually need to know exactly what that something is.¹

Secondly, the domain only needs to know about "core" business rules.

In other words, the domain ideally contains all the rules, and only those rules, that would apply to any application using those entities in your business.

You can certainly stretch this either to fit your team's needs, because your little domain library probably isn't used across the organization. But, I've found it to be a good guiding principle -- especially as other groups in your organization ask for endpoints into your application.

Each client (and endpoint) can have certain rules or special steps that need to be done. But, only those rules that would apply to all possible "clients" or "applications" belong in your domain.

Everything that seems to apply to a single client's service or "application" belongs in that particular client's service or application² ...

^{1. Unless your core software, and therefore your domain, is precisely about managing persistence! You'd have a hard time writing the domain layer for a file system that doesn't know about files!}

^{2. Though he's not necessarily talking about DDD, Uncle Bob rants about this a lot. (And, I mostly agree with him on that point.)}