This is important stuff wrt overall ease of use for Sculptor - from a newbie/novice viewpoint I'd say this is one (rare) area where the docco is a little light on, maybe because initially it was expected to be simple - i'd think we should have all scenarios identified (maybe in a table), including default cascade values and maybe with depiction of equivalent uml constructs etc.
You mention that by aggregate we really mean composition and i wonder do we need equivalent of both a uml composite and aggregate? Knowing that an object can exist standalone would seem to determine whether it needs have an identity. BelongsTo does suggest composition whereas mayBelongTo could be used for aggregation? That would be a way to enable identity for those items. While we're at it, it would be neat if we could include some construct to indicate that an entity can only be deleted when not referenced in any (one-way) directed relationship. I've had that scenario recently, its neither aggregation nor composition in the std uml sense but it maybe can be regarded as another significant form of 'collection' just as DDD has identified the aggregate form as being significant and has fleshed out specifics of the concept, beyond whats presently defined in uml. Incidentally i recall seeing a screencast of Eric E explaining that he'd realised he didn't quite have the 'aggregate' concept defined correctly in the DDD book. I never got to watch it all the way thru so will try to hunt that down now to see what he was saying or whether he's published any revision of the book .. Patrik Nordwall wrote: > > What do we need to improve related to aggregates? > > To clarify the terms, I'm actually talking about composition (filled > diamond in uml), but I call it aggregate because that is the term used in > DDD. See our description here: > http://fornax.itemis.de/confluence/display/fornax/3.+Advanced+Tutorial+(CSC)#3.AdvancedTutorial%28CSC%29-Aggregate > > Two important rules for aggregates: > - Only the root entity can be linked to from other entities and the > contained entities and values are only accessible through the root. > - Only the root entity can have a repository, i.e. it is not possible to > fetch and save contained objects separately > > Right now we can do define aggregates with 'not aggregateRoot' > > Entity Planet { > gap > String name key; > String message; > - Set<@Moon> moons opposite planet; > > Repository PlanetRepository { > findByKey; > save; > findAll; > } > } > > Entity Moon { > not aggregateRoot // belongs to Planet Aggregate > String name key; > - @Planet planet opposite moons; > } > > The first thing we should remove is the limitation that this can only be > used for Entity. There is no reason why it shouldn't be possible to do the > same for ValueObject. > > Maybe it would make it easier to understand/read by using something like > 'belongsTo' like this: > > Entity Cargo { > - TrackingId trackingId key > - Location origin required > - Location destination required > - Itinerary itinerary nullable opposite cargo > - Set<HandlingEvent> events opposite cargo > > } > > ValueObject Itinerary { > belongsTo Cargo > - Cargo cargo nullable opposite itinerary > - List<Leg> legs > } > > ValueObject Leg { > belongsTo Cargo > - CarrierMovement carrierMovement > - Location from > - Location to > } > > belongsTo doesn't really add any more information to the model than 'not > aggregteRoot', but I think it would be good to introduce it anyway, as an > alternative syntax. > > Do you think we need something else? > > For Google App Engine we added hint="owned" for references, but I think > that was wrong. Specifying ownership on the associations doesn't really > make sense, does it? > > /Patrik > -- View this message in context: http://old.nabble.com/-sculptor--Aggregates--tp28332528s17564p28335323.html Sent from the Fornax-Platform mailing list archive at Nabble.com. ------------------------------------------------------------------------------ _______________________________________________ Fornax-developer mailing list Fornax-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fornax-developer
