Niclas Hedhman wrote: > On Tue, Sep 16, 2008 at 11:25 AM, Niklas Uhrberg > <[EMAIL PROTECTED]> wrote: > >> Just look at the important case: >> >> Entity within Aggregate id=X -> Entity within Aggregate >> id=Y is invalid >> >> >> This is a strong constraint , probably violated by many projects and >> people will in the worst case misuse Qi4J just to get around it. >> > > Well, we need to explain how things MUST be done and have convincing > arguments why it is that way. > > In reality, I think a lot of "PartOf" entities will be 'promoted' to > "Root" entities as a result. I think it can be rather hard to figure > out differences... > > For instance; An engine is a "PartOf" entity of Car, but the Car can > change Engine and the old one goes in for reconditioning and end up in > a Store for sale. Apparently, the Engine is a root entity in its own > right. > > Ok, we're entering deep waters now. I suggest that we make up a definition or a list of characteristics for root entities vs non-root entities so that we know what we mean.
In the example above, what is it that makes the engine a root entity? Is it that it can move to be a part of another car? Is it that it can be queried for in a repository? Is it that it has an identity of it's own and can survive the car it was originally a part of. I think it depends on the model and the requirements it must support. So in the example above, yes, because it seems that there should be a repository for engines. But, only that fact that the engine can be put in another car does not motivate it being a root. It may suffice that it can be reassigned from one car to another. > So, let's go back to the Order/OrderLineItem scenario. > When the Order reaches the packaging people, they notice that one item > is out of stock (stolen). A RestOrder is created, and often the > OrderLineItem on the RestOrder will reference the original > OrderLineItem, for agreed price, a reference to humans and perhaps for > auditing (paper trail) purposes later. In our suggested constrained > environment, we are asking that an "Aggregate Identity" (Pos) is > provided by the RootEntity (Order) to such OrderLineItem. IMHO, people > do it all the time in the real world. "Front left tyre of my car"... > if you can't find the car, you can't locate the tyre, and if someone > moves the tyres around, the "Aggregate Identity" will change for each > of the actual tyres. > > I don't follow everything here. Do you mean that the OrderLineItem has an identity, but this identity is unique only within the aggregate (root:Order). If so, what does "A RestOrder is created, and often the OrderLineItem on the RestOrder will reference the original OrderLineItem, for agreed price, a reference to humans and perhaps for auditing (paper trail) purposes later" mean? It's fine if the RestOrder.orderLineItem contains the same values for price, but it couldn't refer to the Order.orderLineItem right, Order and RestOrder being distinct roots. (Just to be sure I don't misinterpret...) > Should such a mechanism (Identity within Aggregate) be supported > intrinsically, or just as a recommended pattern? > > Interesting questino, I have no strong opinion but the gut feel is that it should be very simple for developers to adhere to this practice, be it by intrinsic support or not. Also, the perceived difficulty is most often pretty big even for small tasks if they are only slightly dissonant with current practice. /Niklas > Cheers > Niclas > > _______________________________________________ > qi4j-dev mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/qi4j-dev > > _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
