I'm working on a test project, with the intention of using DDD.

So far I have this basic project structure:

enter image description here

My question is: How should the Core.Domain.Services be referenced? do I create an interfaces project like what I did for the application services, and use Dependency Injection ?

Edit: To be more precise, let's say I want to use my Domain Service in an Entity or an Application Service..etc, how do I reference it? do I create an interface for each domain service and use DI ? where does the interfaces and implementation belong (which layer/project) ?

If so, where does such a project belong?

( I will reference this great poste just so we can be clear on my opinion on the when to create a domain service and what to avoid in order not to fall for antipatterns: Domain Services vs Application Services )

  • Your question is too vague/unclear/undefined and possibly based on a misconception. Domain services are part of the domain model, so whatever approach you use to define architectural boundaries and interfaces of the domain model, you'll also use it for them. Also, the domain services can themselves be used to form the interface to the domain layer/model. Jun 2, 2019 at 14:05
  • Thanks for your comment. I understand what you said, and actually my question isn't vague at all. If i need the domain service from an application service, or from anywhere in the application, do I need to define Interfaces to inject that domain service? and where does such an interface belong
    – Dree Droo
    Jun 2, 2019 at 14:29
  • OK, then add your clarification to the question itself (edit). You may think that the way you originally phrased it is clear, but people might interpret in different ways what is it that you are actually asking and what specific aspect of this you are interested to know about. Being precise helps us give you better answers. Jun 2, 2019 at 14:48

2 Answers 2


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.


You are probably having trouble deciding where to put things, because there is no meaningful (i.e. business-related) packages or projects.

Let's look at this pragmatically. I see your design 3 levels deep, yet I have no idea what your project is about.

Also, let's say you make a change. The client tells you to add a new type of product (or whatever your domain actually is), or just an additional displayed attribute to a product. Where would these changes be implemented? I suspect that each (or most) of these projects would have to be modified.

If you were to use the natural structure of the domain instead of a completely generic and technical one, you would have perhaps less problems finding the right place for things, and probably even have better maintainability at the end.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.