Sean,

I'm glad that you liked the presentation.

The MoneyTransferService I describe in the presentation is a simplified but typical service in the applications I work on.

public class MoneyTransferServiceImpl implements MoneyTransferService {

    public MoneyTransferServiceImpl(AccountRepository accountRepository,
            BankingTransactionRepository bankingTransactionRepository) {...}
    }

    public BankingTransaction transfer(String fromAccountId,
            String toAccountId, double amount) throws MoneyTransferException {
        Account fromAccount = accountRepository.findAccount(fromAccountId);
        Account toAccount = accountRepository.findAccount (toAccountId);
        fromAccount.debit(amount);
        toAccount.credit(amount);
        TransferTransaction txn = new TransferTransaction(fromAccount,
                toAccount, amount, new Date());
        bankingTransactionRepository.addTransaction(txn);
        return txn;
    }

}

(and, yes, this could probably be shorted to return fromAccount.transferTo(toAccount, amount) , and money shouldn't be a double :-) )

The services are invoked by the web tier, e.g. Spring MVC controller. Each service method is a few lines of code that takes object ids + other data as parameters; calls some repositories to load some entities and then invokes some methods on those entities to do some work etc. You could probably characterize this as an application service rather than domain service but if your services are simple like this one then having a separate domain service isn't generally valuable. However, if the service was fatter and manipulated, for example, XML messages or DTOs, then moving the domain logic into a separate domain service might be a good idea.

Chris

--
Enterprise POJO consulting - http://www.chrisrichardson.net
Author, POJOs in Action - http://www.manning.com/crichardson
Enterprise POJOs blog - http://chris-richardson.blog-city.com
Speaking in 2007 at JavaOne, SpringOne, the Colorado Software Summit, the Spring Experience