Non-domain service interfaces

Question

While learning domain driven design, I have been putting together the following solution (note that this ordering is lexicographic and not a representation of dependency):

Below is an outline of each project:

Domain.Models: Domain entities and value objects (e.g. Order)

Domain.Interfaces: Domain service interfaces and repository interfaces (e.g. IOrderService, IOrderRepository)

Domain.Services: Concrete implementations of domain services interfaces (e.g. OrderService)

Infrastructure.Data: Concrete implementations of repository interfaces (e.g. OrderRepository)

Infrastructure.DependencyResolution: Dependency injection resolution.

Problem

Now I would like to provide non-domain services. An example would be an email gateway for the sending of emails. I have created the following project for this:

Infrastructure.Components: Concrete implementations of non-domain services

Question

Where would I put the interfaces for such non-domain services (for example, an IEmailGateway)?

It would need to be accessible by the Domain.Services project (an OrderService might need you send out a notification), so would it go in Domain.Interfaces? I would say NO since sending an email is not a domain-specific activity.

Answer 1

I would say NO since sending an email is not a domain-specific activity.

Sure, but you could get away by using a higher domain abstraction. The Domain doesn't care about emails but Notifications would be a perfect domain concept. It actually already seems to be part of the Ubiquitous Language, since you used that term in your question. So something along the lines of INotifier instead of IEmailGateway.

Alternate approaches could be :

• Have the overarching Application Service send the email via an IEmailService interface defined in the Infrastructure.

• Have the Order entity or domain service raise a Domain Event. An EmailService in the Infrastructure layer listens to it and sends the email.