Identifying Domain Services & Application Services when doing DDD

Question

-I'm trying to figure out how to identify Application Services in my application. I think I can identify a Domain service by 2 things:

1. It acts as a facade to the repository.
2. It holds business logic that can't be encapsulated in a single entity.

So I thought about this simple use case that I'm currently working on:

An admin should be able to ban a certain user. The operation must be logged and an email must be sent to the banned user.

I have a UserRepository which has a function getUserById(). I have a User entity which has a ban() function.
I'll create a UserService like this:

class UserService{
    static void banUser(int userId){
          User user= UserRepository.getUserById(userId);
          user.ban();
          UserRepository.update(user);
    }
}

The userId is a POST variable that I'll be receiving in my Controller from a web form.

Now where does the logging go? I need to log the ban process twice before and after the operation ex:

Logger.log("Attempting to ban user with id:"+userId);
//user gets banned 
Logger.log("user banned successfully.");

Second, I need to send a mail to the user. where should the call go?

I thought about putting the logging and email is the UserService class itself, but I think there are better solutions.

Third, where do Application Services fit in all of this?

Answer 1

class UserService{
    public public UserService(IUserRepository repo, INotificationService notification)
    {
      this.UserRepository = repo;
      this.Notification = notification;
    }
    public void BanUser(int userId){
          User user= UserRepository.getUserById(userId);
          user.ban();
          Notification.NotifyBanned(user);
    }
}

When it comes to logging then you may choose a lot of solutions. Just log in BanUser method. Create logger per class (like log4j/log4net users do). Or you can inject ILogger in ctor. Or maybe it is some kind of Audit trail. Then maybe IUserAuditTrail would be better?

public interface IUserAuditTrail
{
    void UserBanned(User user)
    void AccountCreated(User user)
}

or sth like that. Or you can add loggin AOP style. Decorate UserService with attribute and use PostSharp or use IoC container and configure interceptor to handle logging for you. Unless logging operations isn't business function and instead it's just for programmers I would go for interceptors. Otherwise IAuditTrail or sth like that.

Answer 2

Domain Service vs Application Service
A domain service is a class that hold a behaviour that does not belong to any other entity or value-object in the domain. Nothing to do with repository. If you model the user's roles, many domain services become methods of the role itself.

Instead applicative services are the interface used by the outside world to use the domain. Thus, UserService is an applicative service.

Handling technical side effects
I use observable entities to handle such domain events.

This way:

• the repository can observe a Banned event and update the persistence state without the need of an explict save call
• the UserService can subscribe the event with an handler that logs and send the email just if the ban() command succeed.

Answer 3

Now where does the logging go?

Second, I need to send a mail to the user. where should the call go?

I would recommend Domain Events. Create two events: UserBanAttemptedEvent and UserBannedEvent (note the past time).

The logic for logging and email notifying is going inside event handlers, create two handlers UserBanAttemptedEventHandler and UserBannedEventHandler.

The *payload classes just simple DTO with useful information like: UserId etc. This approach decouples application logic better imho

void banUser(int userId){
      DomainEvents.Raise<UserBanAttemptedEvent>(new UserBanAttemptedPayload())

      User user= UserRepository.getUserById(userId);
      user.ban();
      UserRepository.update(user);

      DomainEvents.Raise<UserBannedEvent>(new UserBannedPayload())
}

There are many implementations of these pattern, examples:

http://lostechies.com/jimmybogard/2014/05/13/a-better-domain-events-pattern/

DDDSample.Net