Vaughn Vernon in "Implementing Domain-Driven Design" advises the following:
Depending on the purpose of a Domain Service, it can be quite simple
to model. You’ll have to decide whether or not your Service should
have a Separated Interface [Fowler, P of EAA].
Then also gives the following choices:
- Interface can be declared in the same package/module as Aggregate it's deals most with. Vernon uses an example that
authentication interface can be declared in the same identity-specific aggregates as User, Group, etc, because authentication service "is an identity concept".
Implementation can be in the following places:
- "If you are using the Dependency Inversion Principle or Hexagonal, you may decide to place this somewhat technical implementation class in a location outside the domain model." (Ibid)
- "Technical implementations may be housed in a Module in the Infrastructure Layer" (Ibid)
In "Patterns, Principles, and Practices of Domain-Driven Design" Scott Millett and Nick Tune mention different types of domain services. One is about "Representing Contracts" means domain model is interested in the interface only (so it's clear where you need to define it - in the domain model), but implementation may be (in the same way as above) technical, and outside of domain.
Please note, that those are just advises. It all depends on what depends on what. usually domain model should depend minimally on anything else, ideally, it should depend on nothing, in practice - it may depend on some infrastructural facilities. That is, domain can't deal with anything external by itself - it all goes through for example application layer. That is where dependencies are likely to be injected. And objects domain defines interfaces for used.
In short: Interface is to be defined in domain model. Implementation place may vary, depending on the purpose of the service.
Usage of the service can also happen either in the domain model itself or from neighboring level (application level, depends on your architecture), which depends on domain.
PS. I have an impression, than calling package Core is actually against DDD: it's solution space name. Hopefully, you just redacted your project to publish here. Otherwise you better have proper names for concepts instead of Core / Application, etc, etc down to aggregates and services, or at least minimize use of solution-related names to the absolutely minimum convention.
