Niclas Hedhman wrote: > Hmmm, that works up until the point where there is divergence between > the two contexts. Maybe the suggestion is that we do context mapping > (using Hibernate et al) solve the denormalized state view context from > the normalized behavioral context. OR, maybe the solution is that the > state view context is "simple" so it is just a "conformist" context to > the behavioral context. Or do we, with the powerful decoration > mechanisms in Qi4j, maintain a state view model by clever under the > covers Property mapping in runtime (instead of ORM techniques)?
If you look at an Entity it is going to have (at least) 3 layers: the state layer, any domain logic "covering" that state, and then roles used by clients/algorithms. Providing DTO's, or "views" of the internal state, could definitely be seen as one type of role, so it could be implemented by a mixin. If you use aggregates a lot, then it seems logical that these views are primarily created and accessed through the aggregate root (all of this is btw looking like a russian doll, where the inner entities of the aggregate are like the private mixins of one single entity, "as above, so below" etc.). If this is the case, then the aggregate could return something which allows access of specific properties, assembled from its internal structure. Since Qi4j has support for first-class properties, one interesting point is that if those properties in the view returned by the aggregate root comes directly from the internal entity state, as Property<>'s then when they are read or modified, that changes the internal state directly. Note that there is nothing to stop us from doing partial loading of state in the entity store, meaning, an access of a property does *not* have to trigger loading of all state, hence giving us great possibilities for lazy loading and partial loading. > I also strong think that his approach will have us think heavily into > the role of the whole message and 'tell, don't ask' pattern in Qi4j. > Messages have not been fully ironed out, so I think the timing of all > of this is pretty good. I agree. This also touches upon the principles of BASE (Basically Available, Soft state, Eventual Consistency), where messaging and queues are fundamental to scalability. I think that approach is basically correct and should be supported. > You said he will be at QCon London, and I have been thinking lately of > going, actually to meet Eric again. Don't know if Rickard is going > there, but it could be a good time to sit down and get to the bottom > of it with him and Eric. I don't plan on going (I gotta work fulltime on StreamFlow/Qi4j now), but it would be great if you or anyone else on the list could. /Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
