General and technical thoughts on how I use DDD

I am going to step away from my application for a day or two and think about some things. I’d also like to post a few of the things I’m going to be considering in hopes that some of you have some degree of insight for me.

One thing I have an issue with is the use of a single repository per aggregate chain. It simply seems illogical to me to mix the fetching strategies of several different (though related) object types into a single repository. Especially when the base repository is a generic type.

It would seem a better use of separation of concerns to give each entity type it’s own repository. The potential problem there, and I ran into this myself, is having each repository maintain a separate ISession. You will run into issues if you select a custom using the customerRepository, then adding to it an order selected using the orderRepository. The two entities are being tracked by different ISessions and you will get warning to this effect.

I see two alternatives to this. Let your dependancy injector pass in a PerWebRequest scoped ISession to each and every repository, or simply use a static class that leverages System.Web.HttpContext.Current.Items to store one. This was all repositories have the same session and the entities they generate could be used cross-repository.

I simply do not see any reason to force one to fetch and update the customer if all they are doing is adding an item to an existing order. Doesn’t it make more sense to just fetch the order?

Of course you may argue that is what you could, and should do, but then go on to say that I should just add a GetOrder method to my customerRepository. Sure, it works, but as I’ve already stated, It doesn’t much sense to me personally, in terms of separating fetching strategies by entity type.

Does anybody have any insight, comments, thoughts, or additions to make on this?