Niclas Hedhman wrote: > 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) >
Clarification: Entity within Aggregate id=X -> Entity within Aggregate id=Y is 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 ); > > See clarifiaction above. This is not true without the qualification that the associated entities belong to distinct aggregates. >> 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? > > The statement means ( in DDD by Evans ) that access to entities within an aggregate is always done via the root entity. It does not mean that the entities cannot be accessed "as entites", so there is still a point of having entities within aggregates. Example Order.getOrderLines where Orderline in an entity but not a root entity. >> 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? > > Let's delve deeper into the cons of permitting queries for non-root entites, this is one of the least intuitive areas I think. (Most difficult to find cons....) One feeling I have is that making all entities searchable will make it easier not to do design á la DDD by having external Services implement all the behaviour and entites being simple structs. But it needs more thinking.... /Niklas >> 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 > > _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
