Should domain models call infrastructure interfaces?

Question

is the following good design and allowable in onion architecture and domain driven design?

say you have an "Order" domain class like so

class Order
{
  INotificationService _notificationService;
  ICartRepository _cartRepository;

   void Checkout(Cart cart, bool notifyCustomer)
   {
         _cartRepository.Save(cart);
         if (notifyCustomer)
         {
            _notificationService.sendnotification();
         }
   }
}

Is it good or bad design to have the domain model call interfaces of infrastructure?( in this case, notificationservice and CartRepository)

Answer 1

Your design will be OK only if both INotificationService and ICartRepository interfaces are defined within your Domain (Core) layer and if they're bound at runtime with the right implementation by your Dependency Resolution layer (the outermost layer of your Onion architecture).

Remember that in an Onion architecture, your Domain layer cannot reference any libraries.

ICartRepository implementation will obviously be done in your Infrastucture layer as it will surely be tied to your Data Access layer technology.
If your INotificationService implementation needs to talk to an external service, then it goes to Infrasrtructure as well. But if it is part of your business then it's implementation could be in the Domain layer.

Answer 2

I think INotificationService is a domain concept rather than infrastructure service. We could model this as a DomainEvent telling "the customer about the cart is saved".

What about moving the INotificationService to the domain layer and rename it as "CartDomainEvents".

CartDomainEvents.raise(CartSavedEvent(...));

In general case, Calling infrastructure components introduces bidirectional dependencies which is usually not a good design.