In trying to understand Domain Driven Design I keep returning to a question that I can't seem to definitively answer.
How do you determine what logic belongs to a Domain entity, and what logic belongs to a Domain Service?
Example: We have an Order class for an online store. This class is an entity and an aggregate root (it contains OrderItems).
Public Class Order:IOrder
{
Private List<IOrderItem> OrderItems
Public Order(List<IOrderItem>)
{
OrderItems = List<IOrderItem>
}
Public Decimal CalculateTotalItemWeight()
//This logic seems to belong in the entity.
{
Decimal TotalWeight = 0
foreach(IOrderItem OrderItem in OrderItems)
{
TotalWeight += OrderItem.Weight
}
return TotalWeight
}
}
I think most people would agree that CalculateTotalItemWeight belongs on the entity. However, at some point we have to ship this order to the customer. To accomplish this we need to do two things:
1) Determine the postage rate necessary to ship this order.
2) Print a shipping label after determining the postage rate.
Both of these actions will require dependencies that are outside the Order entity, such as an external webservice to retrieve postage rates. How should we accomplish these two things? I see a few options:
1) Code the logic directly in the domain entity, like CalculateTotalItemWeight. We then call:
Order.GetPostageRate
Order.PrintLabel
2) Put the logic in a service that accepts IOrder. We then call:
PostageService.GetPostageRate(Order)
PrintService.PrintLabel(Order)
3) Create a class for each action that operates on an Order, and pass an instance of that class to the Order through Constructor Injection (this is a variation of option 1 but allows reuse of the RateRetriever and LabelPrinter classes):
Public Class Order:IOrder
{
Private List<IOrderItem> OrderItems
Private RateRetriever _Retriever
Private LabelPrinter _Printer
Public Order(List<IOrderItem>, RateRetriever Retriever, LabelPrinter Printer)
{
OrderItems = List<IOrderItem>
_Retriever = Retriever
_Printer = Printer
}
Public Decimal GetPostageRate
{
_Retriever.GetPostageRate(this)
}
Public void PrintLabel
{
_Printer.PrintLabel(this)
}
}
Which one of these methods do you choose for this logic, if any? What is the reasoning behind your choice? Most importantly, is there a set of guidelines that led you to your choice?
I would tend to have an external service determine the shipping rate. For me that's application logic rather then order-specific logic. For example you might decide for a period to offer free shipping for orders over a certain size, or to a particular group of loyal customers. For me that logic will tend to change independently of how an order is constructed.
Most likely I would have the code which is responsible for placing the order (some kind of Order Processor service, in an application layer or in a command handler) hand off to a service to get the shipping rate, and then pass that rate into the order, so I guess option 2.
For printing a shipping label, I'd tend towards having the domain raise an event along the lines of http://www.udidahan.com/2009/06/14/domain-events-salvation/. A separate handler would then deal with printing the label. Again, the logic for this is that the way you print labels is likely to vary independently of how you construct an order, so it makes sense to keep that separate. Using a domain event seems to be the cleanest way of ensuring that the label is printed at the right time without requiring the Order (or indeed the order processor) to be aware of the printing logic.