Correct Erik. The type can map to different types but instances will map to only a single aggregate root.
I don't believe I chose the customer -> order example and you are right I don't like it because its two aggregates. Greg On Mon, Apr 27, 2009 at 5:07 PM, Erik Lundby <er...@gorge.net> wrote: > >>> I thought earlier you had written something about OrderLine belonging > to two >>>different kinds of order, one which was raising and one which was > raised. I >>>can't find it now though so I may have been someone else. > > I think was talking about the class is able to have two different kinds > of parents, but a class instance cannot have two parent instances. The > Orderline class would have to be an IAggregatedPartof<T> for different > T's but an individual orderline would only have one root. I also > suspect that Greg is sorry he brought up the Customer/Order example as > he has stated he knows he would have to go a different direction for a > cross aggregate concern like this. He is talking about removing these > concerns from within the AR boundry. > > > My interpretation, > > Erik > > -----Original Message----- > From: nhusers@googlegroups.com [mailto:nhus...@googlegroups.com] On > Behalf Of Peter Morris > Sent: Monday, April 27, 2009 1:13 PM > To: nhusers@googlegroups.com > Subject: [nhusers] Re: Version > > >> An instance of an entity always belongs only to a single aggregate > root. > > The problem with > the official description of agg-roots is that no persistent references > may > be made to any of the agg-parts. This effectively means that > customer/order > is not an aggregate because you can reference orders independently of > customers. What you need to do though is to ensure that customer is not > > updated by another thread because you need to do > Customer.AcceptOrder(newOrder) so that you can check credit limits etc. > > > >>> > Fetching strategies are meaningless if you store documents. My point > was that they are specific to a RDBMS. If I use document based storage > I have no need for fetch paths. > << > > Yes that's right, but the fetch path was only part of what you gain. If > you > say *why* you want an order then the object which fetches the order + > lines > will also place a lock on the customer, ensuring it isn't modified by > anyone > else because it knows that the reason you need the order is to modify it > and > you will therefore need to ensure that the customer's credit limit isn't > > exceeded. It's not something I have tried yet, just something I'm > thinking > about since watching Udi's talk. > >>> > Various ways most of which are mentioned here. I am really going > through nhibernate right now to see if it is at all appropriate for > use with DDD (this discussion will make a big impact on that > decision). > << > > Keep in mind that I haven't written an NH app yet, so far I have only > read > about it and have yet to get started using it. I usually use ECO from > capableobjects, in which I get bi-directional associations for free. > > > > Pete > > > > > > > -- It is the mark of an educated mind to be able to entertain a thought without accepting it. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to nhusers@googlegroups.com To unsubscribe from this group, send email to nhusers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nhusers?hl=en -~----------~----~----~----~------~----~------~--~---
