0

I am trying to get up and running with DDD and there seems to be some limitations imposed by technology stack in my case ASP.Net that make you think about how things will work together. For example let's say I have created a rich class of ShoppingCart and my ShoppingCart has two methods of AddItem(String Sku) and RemoveItem(String Sku). Now I might have a lot of logic in these two methods with a lot of my business rules validation.

What happens when I want to bind my ShoppingCart to the UI using ASP.Net MVC? Ideally I would like to call the AddItem and RemoveItem methods when the user adds or remove an item on the UI so that I can validate all the rules, but normally we bind the UI to View Models (POCO classes). Thus when the user saves the cart from UI I will get a list of POCO classes that I now need to map to my actual business object. Should I iterate over each item and track it from existing data and call AddItem and RemoveItem methods now?

In this case I need to keep an instance of my domain object in memory for that user so that I can perform operations on it. Even then I will have bulk of logic in controller to decide which methods to call on the Business object.

The more I am thinking down these lines the more confusing it gets because the problem would not happen on let's say Winforms, where you can easily call the respective methods on the Domain object from various event.

What am I missing in this whole picture to make DDD work like it should?

Afraz Ali
  • 2,672
  • 2
  • 27
  • 47
  • Even in Winforms your domain entities wouldn't live forever in memory. They would be loaded from the DB when they are needed, and at some point they would be persisted and garbage collected, hopefully. – guillaume31 May 01 '16 at 09:32

1 Answers1

1

Typically, adding and removing resources would be an http POST call. So, the method on your controller handling this call would receive a model of the request to add or remove an item to the cart. For example:

public class AddItemToCartRequest
{
    public string CartId { get; set; }
    public string ItemId { get; set; }
}


public class SomeController : Controller
{
    // Reference to some sort of repository/data store for shopping carts
    private Carts carts;

    // Reference to some sort of repository/data store for store items.
    private Items items;

    public SomeController(Carts carts, Items items)
    {
        this.carts = carts;
        this.items = items;
    }

    [HttpPost]
    public ActionResult AddItem(AddItemToCartRequest request)
    {
        var cart = carts.GetCart(request.CartId);
        var item = items.GetItem(request.ItemId);

        cart.AddItem(item);
        carts.Save(cart);

        // Redirect to action showing the "item added" or whatever.
    }
}

The idea is that you do not pass rich domain models back and forth to the view. You pass classes that are models of the views and requests that you are using. On each request, you would fetch domain model instances from a repository/data store (i.e, the carts and items fields in the example). The request data only need to specify identifiers of the domain model instances to fetch.

lenkan
  • 4,089
  • 1
  • 14
  • 12
  • Yes I understand this part but to achieve this I will have to contain the original Rich Domain model in memory or in View state or session somewhere to perform these operations which to me seems like an over kill. That's exactly what my question is, is this the right way of doing things with DDD and ASP.Net MVC? – Afraz Ali Apr 29 '16 at 06:49
  • 1
    You would fetch the cart and item from a data store/repository on each request. This is what is illustrated by the carts.GetCart(request.CartId) call. – lenkan Apr 29 '16 at 09:27
  • thank you! your answer has removed confusion from my mind. – Afraz Ali May 02 '16 at 07:10
  • Rich Domain Model is POCO too. See answers to SO questions ['POCO' definition](http://stackoverflow.com/questions/250001/poco-definition), [POCO vs DTO](http://stackoverflow.com/questions/725348/poco-vs-dto) – Ilya Palkin May 02 '16 at 07:48
  • @ilyapalkin You are very right. I updated my answer so that it doesn't reference the term POCO to avoid confusion. – lenkan May 02 '16 at 14:34