Is a domain service used to figure out a value (could be object, list etc) that is not an instance variable of an entity/value?

Question

I was reading this article recently: http://enterprisecraftsmanship.com/2016/09/08/domain-services-vs-application-services/

The writer recommends a class like this:

public sealed class AtmService // Domain service
{
    public void WithdrawMoney(Atm atm, decimal amount)
    {
        if (!atm.CanDispenseMoney(amount))
            return;
        decimal amountWithCommission = atm.CalculateAmountWithCommission(amount);
        Result result = _paymentGateway.ChargePayment(amountWithCommission);
        if (result.IsFailure)
            return;
        atm.DispenseMoney(amount);
    }
}

Why doesn't the WithdrawMoney method go in the ATM class rather than the ATMService class? Surely this is almost as bad as putting all the domain logic in the application service?

Q1) Is it bad practice to use a domain object A (or list of domain object A's into domain object B when domain object A (or list of domain object A) is not an instance variable of domain object B? For example:

public class Customer
{
   bool valuedCustomer=false;

   public void IsValuedCustomer (List<Order> orders)
   {
      if (orders.Count > 100)
      {
           //Do some more logic here e.g. look how much they have spent etc
           valuedCustomer = true;
      }
   }
}

Here the Orders List is passed to the Cutomer class so that it can be determined if they are a valued customer.

Q2) Is a domain service just used to figure out a value (could be object, list etc) that is not an instance variable of an entity/value?

Update

Following on from Ewans answer. Say I had a class like this:

public class Customer
    {
       List<Offer> offers = List<Offer>(); //this is the offers the customer is entitled to e.g. two offers out of ten.

       public void AssignOffers (List<Offer> offers)
       {
          //All available offers (say 100) are passed to this method
          //There is logic here to figure out what offers the person is   entitled to (this could be a LINQ query).  If the person is entitled to an offer then add it to the instance variable list
       }
    }

Answer 1

That is an odd example. I think the key thing about it, and the reason is it a service, is the use of _paymentGateway.

In my view Domain services are used when you have an operation which crosses Bounded Contexts.

You have your ATM aggregate root, with Banks and whatever and a PaymentGateway with Payments and such.

You don't want to combine these into one giant agregate/bounded context but you do have an operation that requires objects from both. You need some object in which to bundle up the domain crossing logic, so you invent an 'ATMService' and put it in there.

Its not a domain object in its own right because it doesnt have data, just methods.

Like you say though it is odd naming to have a service and an object both called ATM and its not clear why PaymentGateway would be in a different bounded context to ATM

Answer 2

re: IsValuedCustomer(List orders)

This is a 'bad' method because either:

• Order should be part of the Customer Aggregate Root. In which case you don't need to pass the orders in.

• OrderCollection is a DomainObject in which case you can have OrderCollection.IsValuedCustomerId(string customerId)

• Customer is a DomainService, in which case it shouldn't have customer data and the naming is odd.

Having said that though, If you were taking an ADM approach where Order was simply a struct or data transfer object. Having a ICustomerValuationService.ValueCustomerFromOrders() could well be a good approach.

In this case Order is your domain object and Customer is a Domain Service

However, this wouldn't be 'classic' DDD (for want of a better term) in my opinion. Which I think assumes you are programming a monolith style OOP app where everything is held in memory, and thus you don't need to pass data objects around.