Domain-Driven-Design question

Question

Hello everyone, I have a question about DDD. I'm building a application to learn DDD and I have a question about layering. I have an application that works like this:

UI layer calls => Application Layer -> Domain Layer -> Database

Here is a small example of how the code looks:

//****************UI LAYER************************
//Uses Ioc to get the service from the factory.
//This factory would be in the MyApp.Infrastructure.dll
IImplementationFactory factory = new ImplementationFactory();

//Interface and implementation for Shopping Cart service would be in MyApp.ApplicationLayer.dll
    IShoppingCartService service = factory.GetImplementationFactory<IShoppingCartService>();

    //This is the UI layer,
    //Calling into Application Layer
    //to get the shopping cart for a user.

    //Interface for IShoppingCart would be in MyApp.ApplicationLayer.dll
    //and implementation for IShoppingCart would be in MyApp.Model.
    IShoppingCart shoppingCart = service.GetShoppingCartByUserName(userName);

    //Show shopping cart information.
    //For example, items bought, price, taxes..etc
    ...

    //Pressed Purchase button, so even for when
    //button is pressed.
    //Uses Ioc to get the service from the factory again.
    IImplementationFactory factory = new ImplementationFactory();
    IShoppingCartService service = factory.GetImplementationFactory<IShoppingCartService>();
    service.Purchase(shoppingCart);


    //**********************Application Layer**********************
    public class ShoppingCartService : IShoppingCartService
    {
       public IShoppingCart GetShoppingCartByUserName(string userName)
       {
           //Uses Ioc to get the service from the factory.
           //This factory would be in the MyApp.Infrastructure.dll
           IImplementationFactory factory = new ImplementationFactory();

           //Interface for repository would be in MyApp.Infrastructure.dll
           //but implementation would by in MyApp.Model.dll
           IShoppingCartRepository repository = factory.GetImplementationFactory<IShoppingCartRepository>();

           IShoppingCart shoppingCart = repository.GetShoppingCartByUserName(username);
           //Do shopping cart logic like calculating taxes and stuff
           //I would put these in services but not sure?
           ...

           return shoppingCart;
       }

       public void Purchase(IShoppingCart shoppingCart)
       {
            //Do Purchase logic and calling out to repository
            ...
       }
    }

I've seem to put most of my business rules in services rather than the models and I'm not sure if this is correct? Also, i'm not completely sure if I have the laying correct? Do I have the right pieces in the correct place? Also should my models leave my domain model? In general I'm I doing this correct according DDD?

Thanks!

Answer 1

DDD works best when services (application layer) expose only commands on domain objects, not the objects themselves.

In you example I would create a service method like Purchase(strng productName, int quantity) which internally would get a ShoppingCart from Repository (don't have to use interface here) get a Product (by its name) from Repository and call cart.AddProduct(product, quantity)

not, the business logic of adding products to cart, calculating total amount, total weight or other business stuff is encapsulated in the mode.

Answer 2

When you ask

Should my models leave my domain model?

I would say that if at all possible you should work to avoid shuffling data back and forth between different sets of objects in one program. Doing that would result in you going through a lot of tedium writing a lot of boring and error-prone code, you will have a redundant set of DTO objects that have to mirror your domain objects, also you get less mileage out of the methods you write because they only operate on either the DTOs or domain objects. All in all it is very painful and doesn't accomplish much. I try to have one set of domain objects that is passed around throughout the application.

(That doesn't mean there aren't cases where you really have a need to move data between different sets of objects, like when building an anti-corruption layer. Just don't go looking for trouble if it's not absolutely necessary.)

As for

IShoppingCart shoppingCart = repository.GetShoppingCartByUserName(username);
//Do shopping cart logic like calculating taxes and stuff
//I would put these in services but not sure?

one of the goals of Domain-Driven Design is to try to separate business logic from infrastructure code. Whatever you can figure out how to calculate using only the domain objects is better off going into the domain model, where you can write tests for it that do not involve the database. I would want to have the service pull an aggregate of domain objects, then have the business logic calculations happen in the domain objects, then have the service save the state changes that the calculations brought about in the domain objects.

Answer 3

You should have one thin layer between domain objects and services to manipulate with domain objects (recommended by Eric Evans). This object name is usually ending on “Manager”. For example PurchaseManager or similar. All logic that connect different domain objects (user, purchase, address …) is in this object.

• Service call Manager.GetSomething()
• Manager get data from different repositories, do business logic and return result
• Manger Return Result but never return domain objects itself ! If you have domain object called User you should stick with naming convention you invent and map User to UserDataContract or similar. Don’t expose domain objects. It is extra work but you should not couple your domain model with UI.
• Many times domain object has methods to do some business logic

Answer 4

Thanks for everyones reply. However I think I'm even more confused than I was. Ok, I understand the point where a Application Layer should be a thin layer. What type of object should the Application Layer have to transition from UI Layer to Domain Layer? Should it be a Application Service, factory or something else and should it be an instance or static?

Why shouldn't a service have business logic? I thought that was the point of a Domain Service? For example a TaxService?

Does the repository call the business logic on the model? For example check to make sure username didn't go over max allowed credit for the account?

By what I've read my application should look more like this(btw, I vision better when I see code.)?

//**********************UI Layer**********************
//Once again IShoppingCart and ShoppingCartFactory would be in the Application Layer.
//This is the UI calling into the Application Layer
IShoppingCart shoppingCart = ShoppingCartFactory.GetShoppingCartByUserName(userName);



//**********************Application Layer**********************
static public class ShoppingCartFactory
{
   IShoppingCart GetShoppingCartByUserName(string userName)
   {
      IShoppingCartRepository repository = ImplementationFactory.GetImplementationFactory<IShoppingCartRepository>();
      return repository.GetShoppingCartByUserName(userName);
   }
}


//**********************Infrastructure Layer**********************
public class ShoppingCartRepository : IShoppingCartRepository 
{
    public IShoppingCart GetShoppingCartByUserName(string userName)
    {
          //Do DAL stuff to get all shopping items
          IShoppingCart shoppingCart = GetDataFromDAL(userName)

          IUserRepository repository = ImplementationFactory.GetImplementationFactory<IUserRepository >();
          double creditLimit = repository.GetCreditLimit(userName);

          //Maybe this service be a static rather
          //and instance?  Also someone said 
          //services shouldn't have business logic so I'm
          //assuming this might be wrong?
          ITaxService service = ImplementationFactory.GetImplementationFactory<ITaxService>();
          double taxes = service.GetTaxes(shoppingCart);
          shoppingCart.Total = shoppingCart.GetTotalForAllItems() + taxes;

          //I know this is a kinda a silly example.
          if(shoppingCart.Total > creditLimit)
          {
              //Do some logic to disable some Items
              //or put some type of error telling 
              //the user to remove some items.
          }
    return shoppingCart ;
    }
}


public class UserRepository : IUserRepository 
{
    public double GetCreditLimit(string userName)
    {
          //Do DAL stuff to get credit limit.
          ...

          return creditLimit;
    }
}

//**********************Domain Layer**********************
public class TaxService : ITaxService
{
      public double GetTaxes(shoppingCart)
      {
         //Do logic to return how much taxes
         //based on amount and state.
         ...

         return taxes;
      }
}

Anyway I"m still not sure if I'm grasping everything? Once again thanks for everyones help.