I just wanted to elaborate a bit on Udi’s comment to give you a hand in understanding how you could accomplish this and keep your domain model free of these concerns. As I wrote my response, I realized I had enough material for a simple blog post, so I will redirect you to it:

http://www.mariopareja.com/blog/post/2009/04/20/How-To-Avoid-Accessing-Repositories-from-Domain-Objects.aspx

I am not sure why your CreateOrder method would need to load products from the repository. Wouldn’t you be adding (ie. passing in) products to the order? Anyway, the post puts forth a slightly different (and obviously contrived) example.

I’m actually against objects in the domain model accessing repositories, or IoC containers. In other words, they don’t “need to access, say, a Repository”.

One of the ways to keep the domain clear of that is for the service layer to retrieve all needed objects itself and pass those into the domain.

Does that help at all?

Until they need to access, say, a Repository. It is my understanding that the repository interface is part of the domain, however the implementations are infrastructure concerns and so will be provided via DI.

Would this be fair to say?

If so, and an Order took an IProductRepository as a constructor parameter, this either places a dependency on IProductRepository on the Order class (or CreateOrder method), or the CreateOrder method actually calls IoC to get an instance of an IProductRepository.

But Domain should not be calling IoC? If it doesn’t, then we end up passing lots of dependencies around the place just because one method or constructor requires it deep within the object graph or deep within the call stack.

I don’t know what I’m actually asking here, it’s more a illustration of how I don’t quite ‘get’ how we isolate the domain while keeping it usable, and also patterns for IoC usage within DDD focused applications.

You’re looking at how to extend the behavior of the system, but from the domain model out. Often, the best way to extend a system is “around the edges” by adding an additional bounded context.

So, yes, I’d say that by and large, domain objects are free of this concern.

Thanks for the clarification. Let me say it back to you, and please correct me if I am wrong.

You appear to be saying the domain itself does not need to support external extension, i.e. if there is a derived type such as GovernmentUser, it will *also* be part of the domain.

This of course makes sense – the domain encompasses all aspects of the problem.

I am trying to alleviate a nagging technical concern: “leave room for unknown derived types”.

Would you say that domain objects are free of this concern?

I myself was interpreting comments made by someone else so we’re both in the same boat here

Domain model objects are designed to collaborate with each other intensely in their implementation of business rules. They should not be talking to anything else outside the domain, thus there is no need for DI in there. For that reason, there is no technical reason that one domain object cannot instantiate another directly (although we should NOT be seeing A instantiating B as well as B instantiating A).

That is, until you think about how you’re going to take these and stitch out of them a single result shown to the user. This is the advanced side of DDD and ties into SOA, so I’ll leave it for a different post.”

I guess introducing a third bounded context here seems complex to me, but I’m wondering if I have a different interpretation of bounded context than you. To me if generating taxes relates specifically to ordering, and if you don’t have the signs of a bounded context waiting to appear (false cognates and duplicate concepts), then just having a seperate set of classes or a seperate module seems like it’d be a good option.

Very interested in reading more though, especially as to how it relates to your SOA boundaries.

I don’t know if that is the way to go either especially in a broad spectrum e-commerce application. Let me explain using some other “pre DDD” principles

When analysing the Domain one may come to the conclusion that there is a one to one mapping between Customer(Role of a User), User and Account. If that is the case one may fold the three of them into one class and call it whatever it makes more sense for the Domain (say User).

But what if there isn’t a one to one mapping between them? This is very common in E-Procurement systems. Would you ask the customer, would you ask the account or would you ask the user to create an order?

Tricky no? Not really

Use the class that is the most representetive of the party envolved in the business transaction. It may well be the Account.

Furthemore think very well if one needs to subclass the Customer (say GovernementCustomer). You may end up with a bloated and rigid model (FederalGovernmentCustomer, LocalGovernementCustomer, etc etc etc). One may simple need an OrderDescription class (http://knol.google.com/k/stephen-palmer/the-description-class-archetype/3e0t9wv30hso7/6#)

So we would do something like:

IOrderDescription od = OrderDescRep.Load(acc)
aOrderDescription.MakeOrder(acc, // data //).

If OrderDescription starts being too limited but still generalisable to a sub class of customers is preferable to start subclassing the OrderDescription then Account (say GovernmentOrderDescription).

Cheers

Thanks for your response.

> I’m not quite sure what a DI violation is.

I simply meant invoking a concrete constructor, which carries a certain stigma.

> I can say that the dependency inversion principle doesn’t provide much value within a domain model.

Would you elaborate? I am unsure of the impact of technical patterns like DI on the development of domain objects.

> Also, not quite sure how building cars in parking garages relates

It was an argument for keeping factories and repositories separate: you don’t generally store something the same place you build it.

The CreateOrder method on the specific user classes (like GovernmentUser) would directly instantiate Order.

I’m not quite sure what a DI violation is.

I can say that the dependency inversion principle doesn’t provide much value within a domain model.

Also, not quite sure how building cars in parking garages relates

Thanks for your comments though and interested in hearing your response.

“… if you needed to add elements inside a pre-existing Aggregate, you might create a Factory Method on the root of the Aggregate… Another example would be to place a Factory Method on an object that is closely involved in spawning another object, although it doesn’t own the product once it is created. When the data and possibly the rules of one object are very dominant in the creation of an object, this saves pulling information out of the spawner to be used elsewhere to create the object. It also communicates the special relationship between the spawner and the product.”

He then goes on to give an example of Brokerage Accounts having control over the creation of Trade Orders (due to knowledge of allowance rules and initial population data), even though they are not part of the same Aggregates.

Always hard to keep these things in mind though…

If it doesn’t use a factory, is that a DI violation?

If it does use a factory, does User take a factory reference? Is that an appropriate level of knowledge for an aggregate root, or any non-service domain object?

I am inclined to think that factories are appropriate in all cases. They are solely responsible for expressing object creation (and algorithmic differences, such as with GovernmentUser).

Factories and repositories are separate components of an entity’s conceptual lifetime. Combining them by definition violates SRP and really only makes technical sense; you don’t build cars in the parking garage.