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.
> 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...
>> 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
