views:

66

answers:

1

In my implementation I have a service layer to service my Aggregate roots. One of my aggregate roots is an order, to wich I have an OrderService.

For reference, the project is Asp.Net MVC.

On the update order page in the presentation layer a user can update their OrderLines. When the data is posted back to the server these are the actions I am currently taking:

  1. Calling OrderService.GetOrderById(orderId) to get the order being updated.
  2. Update the order instance I just received from my OrderService.GetOrderById with the data that was posted from the form in the presentation layer.
  3. Then I call OrderService.UpdateOrder(IOrder order) with the updated Order instance.

Is this a good/common way of doing things...it seems semi logical and easy to follow on the one hand but also seems as though I might be doing too much by pulling the object out of the repository through the OrderService, and then updating it....and then putting it back. Needless to say I am still finding my way around DDD.

What are your thoughts on this approach?

A: 

Another option is to create an aggregate root for your order line items. In a typical shopping cart scenario you'll have a ShoppingCart (aggregate root) which is a list of line items. Once a user proceeds to checkout an Order (aggregate root) is created from the ShoppingCart line items. You can not add/remove line items from an Order. If you want to edit the order you go back to your ShoppingCart and perform your add/remove on the ShoppingCart and then create a new Order object once the user proceeds to checkout again. The ShoppingCart is cleared out once the Order has been finalized.

The reason for this is that a ShoppingCart and Order are two very different roles. For an Order you'll want payment info, shipping and billing address, etc. which are concerns that do not belong in a ShoppingCart. And an Order would not support add/remove/edit on line items.

Todd Smith