Niclas Hedhman wrote: > On Tue, Sep 16, 2008 at 10:12 AM, Niklas Uhrberg > <[EMAIL PROTECTED]> wrote: > >> Niclas Hedhman wrote: >> > > >>> 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 >> > > Correct, my oversight... which indeed then makes the Association issue > a lot harder, as the owning Aggregate must be known by all in the > hierarchy (or very expensive traversals). > > >> 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.... >> > > Isn't then the Query somewhat in opposition with Aggregates hiding its > internal structures? I mean, if you don't know the "bits" how can you > create the query for searching for them? Would then that suggest that > 'aggregate external' queries are not allowed? I.e. I can only search > the "bits" if the Query is created within the Aggregate... My initial > feeling about that is "Gooooood" as it encapsulates internal > structures and a clean separation of what really is public can be > achieved. > > Yes, being able to query for non-root entities is at odds with hiding the internal structure.
And I think forcing design using aggregates hiding internal structure is just in line with the modules and layers constructs, i.e. it's hard to argue in favour of using modules and layers and not wanting aggregates encapsulating internal structures.... Having said that, I suspect that designing with aggregates the way described here is a lot harder than not doing itm so we get the dilemma of misusing/not using the technology... Now this is not in itself an argument against the "strict aggregate" concept, but it's probably a very good thing to have tutorials and the like addressing scenarios where they are needed and where they are overkill. 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. /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
