domain interaction with other services should be through interfaces

keep implementation details out of the domain, but avoid anemic domain models.

One way to accomplish this is to have the domain define an interface that the infrastructure project implements.

Example

public interface INotificationService
{
  public Task Notify(string message);
}

public class DomainEntity
{
  private readonly INotificationService _notificationService;

  public void DoSomething()
  {
    _notificationService.Notify("I did something");
  }
}

This could be an HTTP call. It could create an event that's sent to a Message broker. It could change between them as requirements change. The beauty is that the domain never needs to know or care: it should send a notification with this content, and the implementation detail is irrelevant.

Caveats

A private readonly property, as shown above, typically doesn't work: if the entity is being retrieved from a repository (e.g. an Entity Framework database context) it won't be automatically injected, and will have to be set afterward by the Application project.

This also means that before any use of the service it will have to be checked for being null.