Niclas Hedhman a écrit : >> What about composites whose Identity impl comes from a private mixin? > Well, for Entities, this is not possible. Since > > module.entities( Abc.class )... > > will ensure that the resulting Composite indeed implements EntityComposite, > which is a subtype of Identity. The way the State is handled internally to > the Composite, any "@This Identity id;" reference which users may perceive > as a private mixin, will be the same Identity as the one implicitly > introduced in the above method call. So, for any existing code, I don't > think there is an issue. > > For non-entities, I think it is a non-issue and we simply require values to > have public Identities. Roger that.
> > 3. Semantically, I don't think that the toEntity() should bother to >>> validate (or modify) the referenced entity with the value held in the >>> Association, just take the Identity as-is. I am thinking of the Rest API >>> usecae, where the toValue() would only pass the identity back to the >>> client, which avoids "pulling in everything". >> LGTM >> >>> HOWEVER, it might make sense to make a distinction between a regular >>> Association and an @Aggregated one... >> Do you mean that (de)serialization of @Aggregated associations should >> traverse them instead of only handling identities? > > Yes, that is a possible semantic option, which *I* don't have a strong > opinion about yet. But if we relate @Aggregated to the Aggregate concept in > DDD, which effectively requires that operations on Aggregates (but only on > Aggregates) to be atomic, then it would make sense to traverse the entire > entity graph and convert to Values... At first sight I can't see why this could be problematic. And yes, closer to DDD. As a side note, the ElasticSearch state indexer do something like this to record @Aggregated entities in order to ease traversal queries generation. What do you others think about this? /Paul
