Take the 2-minute tour ×

-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);

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?

share|improve this question
I would not have a ban method on the user entity. Instead, I would add a new method to the admin entity called Ban(User useruserToBan). You do have an admin entity right? –  MattDavey Feb 20 '13 at 9:33
@MattDavey yup I have an admin entity, but that's not the problem actually. I'm more concerned with the application work flow. –  Songo Feb 20 '13 at 10:17
I know, that's why it was a comment and not an answer :) –  MattDavey Feb 20 '13 at 10:22
@MattDavey all comments r wecomed :) –  Songo Feb 20 '13 at 12:42
add comment

2 Answers

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.
share|improve this answer
add comment

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);
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.

share|improve this answer
add comment

Your Answer


