On Mon, Sep 15, 2008 at 4:19 PM, Rickard Öberg <[EMAIL PROTECTED]> wrote: > Aggregates may have references to Entities within them, but no Entity > may have a reference to an Entity within another.
Aggregate -> Aggregate (ok) Aggregate -> Entity (ok) Entity -> Aggregate (ok) Entity -> Entity (invalid) Agree. > Therefore, if we have > a way to mark an Entity as being an Aggregate root, then for each > Association from an Entity to another we can detect whether the > associated Entity is within the same Aggregate by simply checking if it > is marked as an Aggregate. If you see my other post, if the Association contains both the source and destination, it becomes a simple validation rule within the Association class itself. if( !src.isAggregate() && !dest.isAggregate() ) throw new InvalidAssociationException( this ); > Also, if there is a schema change any rules for transformation of > existing data should be applied to the Aggregate rather than single > Entities. Properties may have been moved from one Entity in the > Aggregate to another, and this cannot be handled if we view all Entities > as "the same". If however we view the Aggregate as being the unit to be > migrated, it's fine. More importantly, the Aggregate construction could be of different set of entities. (I think we need terminology for the non-Aggregate) > Another thing which becomes simpler is serialization. Only aggregate > roots can be serialized, and Entities within it can almost be viewed as > being identity-less for the purpose of serialization. Well, kind-of... > All access to an Aggregates internals comes through the Aggregate root. ... if that is the case, why have the internal entities at all?? If I can't "take" an entity from one aggregate and assign it to another, what's the point? > If you then consider what was stated in the Amazon research paper on > almost-infinitely scalable systems, it feels like those methods quite > often should be message-oriented, i.e. when invoked they will be sending > a message to the Entity rather than just invoking a method in an > RPC-style. The message should assume that it's potentially going over a > network, so doing it in a document-style and asynchronously is probably > a good idea. There's lots of interesting things that can be done here I > think, when it comes to calling Aggregate methods and automatically > convert them into messagebased conversations. I think ~4 years ago I wrote a blog entry about the "brokeness" of RPC, and argued that a conversation-styled interaction should be developed. I argued that in the real world there is no "contract" between how two parties interact conversationally. If I don't understand what you are saying, I can ignore you or make a guess what you mean, and more importantly I can learn what you really mean without you changing your way of communication. I am sure that a whole new set of problems would develop as a result, but I think that the "natural order" is more evolution-friendly... Anyway!!! > As for Queries, one question is whether it should be allowed to Query > for Entities within an Aggregate. But, since the references into an > Aggregates Entities is maintained automatically I think it might be ok > to "find" Entities within Entities this way. The main rule is to not > have references to those Entities from Entities in another Aggregate, > which is the main problem to be avoided. Yes. The query should probably be allowed, but if there is no reference back to the "owner" then assign to a new aggregate is not far away. But then, I wonder, shouldn't it have a reference to the owning Association instead? > These are just some of the thoughts on Aggregates. However, it seems to > me that the main API change might be to have an AggregateComposite > subtype of EntityComposite, which is used as a marker interface for > Aggregate roots. Most of the other logic follows from that I think. Not > sure if the Aggregate root has to have any new methods, but that might > be required. I am not confident that there should be a Aggregate subtype but not a "Owned" subtype. Can an Aggregate be "Owned"? Probably. So we are looking for two types, where Aggregates can only own the "Owned" types?? It feels a little bit like the Composite supertype, which we have found is not clever to use for "everything else". More discussion needed on this topic, but in general I totally agree that we need "something" and we have discussed this on and off since last year, so I feel good that we are now taking some actions. Cheers Niclas _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
