Niclas Hedhman wrote:
> On Tue, Sep 16, 2008 at 6:59 PM, Niklas Uhrberg
> <[EMAIL PROTECTED]> wrote:
>
>> Niclas Hedhman wrote:
>> 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.
>>
>
> The last choice also implies the first and probably the second. As you
> said, DeepWaters. But I think it is these kind of definitions that
> will define the life of future Qi4j developers, and they will express
> a lot of appreciation if we get it right (and hate our guts if we
> don't)...
>
>
>> 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.
>>
>
> Agree.
>
>
>> 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.
>>
>
> But "re-assign" is something that Java doesn't have, and we would need
> to support either with a exposed method in Qi4j API to do exactly
> that, or allow a non-root to have no owner, and the client code do a
> "null assign" first, followed by the new location assign.
>
>
True, re-assign is not a language feature.
We (or perhaps only I) need some conceptual analysis at this point:
There are several aspects to consider: global and local identity for
entities, re-assigment and atomicity, the implementation concerns for
re-assignment vs.
re-assignment purely conceptually.
Now, if we require that non-root entities inherit their identity from
their root (i.e. they have a unique identity only within the scope of
their aggregate) it follows that
they cannot be re-assigned. Correct?
So this seems to be the most important question ATM.
I simply assumed that non-root entities can have global identity, but
this may be an error on my part!
It's just so common to let almost everything have a global identity even
if it's not necessary.
In this example we have an engine that can be a part of a car, but
doesn't have to be that all the time (in the application/model not for
technical reasons)
This makes things easier (i.e. it's pretty clear that it should be a
root, searchable while in the store e.t.c. ).
I'm hard pressed to come up with an example of something that should
have global identity, be re-assignable and not being a root entity.
A common example of things that are parts of another thing is body parts.
But even body parts are candidates for re-assignment (transplantation),
what should we say about this case?
In a system for transplantation each body organ would be (probably) be a
root entity, with a global identity despite the "normal intuition" would
be that they are an intrinsic part of me (the root).
To allow a non-root to "have no owner" (i.e. not be a part of an
aggregate) seems to be a contradiction in terms, but assuming that we
allow it to change owners I think the technical details of
null-assignments and the like is a different matter.
I suspect that the property of being a root entity signals that it
should /be the root of an aggregate with more than one entity in it. /
But this will often not be the case if only roots have global identity
and reassignment implies global identity.
My conclusion now is that only root have global identity....
>> 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?
>>
>
> OrderLineItem on an actual Order (you know, those paper versions that
> pre-dates computers) has a "Pos" or "Item" number column to the left.
> So, used by humans to say "Order 5672 Item 5" to refer to a particular
> line item. In my dad's company, things could be out of stock and a
> RestOrder is created, referencing "Order 5672 Item 5" to avoid the
> recipient of the RestOrder going "uhhh, I didn't order this...". Also
> (in the case of my dad's trading company), before the RestOrder was
> completed, the original Order was still open, so any additional items
> of the same could trigger additional discounts, which all was handled
> within the "scope" of the original Order, and the RestOrder reflected
> that. OTOH, I guess the RestOrder could be viewed as a Report instead
> of an entity, but then "ShippingDate" becomes complex, as since each
> unit of each item (4 of 6 Balls shipped 1 Sept, 2 Balls shipped 7th
> Sept), bla bla...
>
> So, I think what I am trying to say; Although we should disallow
> non-root references in other Entities, I think that we need to provide
> a mechanism (either a feature or a pattern) for an Aggregate to hand
> off a reference ("Item 5") to an internal part, which one can use in
> communications with that Aggregate later. And as the wheels on the car
> try to illustrate, that reference is NOT to the actual entity but a
> place-holder, i.e.
> Association<Wheel> frontLeftWheel();
> the Car aggregate can hand out a "frontLeftWheel" reference, instead
> of the actual Wheel identity...
>
>
OK, good explanation. I follow you now.
Will have to think before I open my mouth....
/Niklas
>
>>> 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.
>>
>
> And I would like to add, Simple Concepts that are hard to explain are
> perceived Complex for little practical reasons.
>
> As for "current practice" --> I am not the guy to be asked... I
> typically don't adhere to "Best Practices", since there are often
> BetterWays around if you look...
>
>
> 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
