On Sat, Feb 7, 2009 at 6:10 AM, tao wen <[email protected]> wrote: > Sum it up, it is ok to have different form of domain model for nearly the > same thing, as along as it is required either for efficience or for better > modeling the problem at hand. It is possible read and write being splitted > into two models, for scalability or forcing us thinking and writing code > without getters/setters, but I don't think it is a MUST-HAVE. Sometime we > can expose getters in domain model, sometimes we can have toXXX method to > transform the domain model to another readable form, or sometime we can have > a separate domain model for reading purpose, the user decide not the > framework.
So, is it just a matter of that; "For the strong domain model we have a pure behavioral model, which somewhere under the hood of each object has state which is not exposed. And then in another context (state view), we allow that state to be retrieved directly." ? 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)? 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. 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. Cheers Niclas -- http://www.qi4j.org - New Energy for Java _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
