Injecting services into domain model objects tends to complicate things more in the long run. Same goes for repositories.

Thanks.

public class Order
{
public virtual Money CalculateCost(IOrderCostCalcService srv)
{
Money cost = Money.Zero;
foreach (OrderLine line in srv.GetOrderLinesForCalcCost(this.ID))
cost = cost.Add(line.Cost);
cost = cost.Add(this.ShippingCosts);
return ApplyTaxes(cost);
}
}

I don’t consider this an issue. If you can do everything you need by calling a single (one and only one) method on the interface which you retrieved (it’s OK to pass in other objects which you retrieved or created as parameters), then you should be fine.

I’m quite new to DDD and something I have recently been contemplating (and battling with) is a rule suggested in Evan’s book that only Aggregate Roots can be obtained directly with database queries, everything else must be done through traversal.

In the example above (and in many attempts I have made to use the repository pattern with a generic repository), it seems appropriate to request an implementation of an interface that isnt the (necessarily) the implementation of your aggregate root.

The example code requests and returns an implementation of IOrderCalculator from the repository. This may or may not be the aggregate root (order). Do you see this as an issue?

Query performance is not the primary driver. Decreasing the number of SELECT statements hitting the DB in an OLTP scenario (affecting overall throughput) is a big one – yet not the only one.

Once I have that interface, I can hook other behaviors on to it in the same fashion – IAuditor, ISecurity, etc. In other words, I get flexibility.

Anyway interesting stuff.

In actual fact we have a similiar approach to your IOrderInfo, but ours is just an OrderInfo class and its certainly not domain related at all…its even kept in a seperate Domain.Presentation assembly and doesn’t get loaded by a repository.

IOrder o = Repository<IOrder>.CreateNew();

Now to your question:

One way is to keep the interfaces as part of the model and have the concrete classes explicitly implement them – “forcing” developers to access them via the interface.

The second way leverages the fact that the service layer doesn’t have to depend on the concrete classes at all (helped by DI). To the service layer, the interfaces are the domain model, and the concrete classes “just” one implementation of it. In short, two projects – one for interfaces, the second for implementation; DomainModel and DomainModel.Implementation if you will.

Finally, I don’t so much view it as “a place for defining extra functionality” but rather the best way to express my design intent – exposing precisely what is necessary but no more – YAGNI Decreased coupling and the Single Responsibility Principle round it out nicely.

Configuration, whether with XML or code, as long as it’s separate from the domain model is what I like.

OrderCalculator would contain a list of OrderLines, but not as IList, but rather IList<IOrderLineForCalculation>.

IOrderCalculator order = Repository.FindOne((Where.Order.Id == orderId));

It tells me that you have defined (probably confiugration) that when I try to load IOrderCalculator, I
would run through an IFetchStrategy, and then load Order which in this case would get me its OrderLines as well. This means that the knowledge about this is located in the configuration, right.

I thought about doing this is with:

[RequiresFetchOf("OrderLines")]
public virtual Money CalculateCost()

But the problem is that then the service has no good way (except strings) to pass this knowledge to the repository.

So probably it would be better to put the attribute on the interface itself, and have the repository read it and invoke the appropriate fetching strategy.

“OrderCalculator would contain a list of OrderLines, but not as IList, but rather IList” – looks like you missed the end of the sentence.