Hi, I prefer context mapping here. As the indexing process is some sort of context mapping, it maps the domain model into the index view. And in previous discusion on this list, you suggested RDBMS can be used, but used as async backup/archive is also some sort of context mapping (ORM). Greg mentioned that, he is using a a message bus to broadcast the event, and let each bounded context listen for the event and map things to their own context. I also saw this kind of async publishing/subscribing context mapping thing in eBay architecture presentation as well (although I am quite a newbie to large scale architecture).
Here the context might be more large scale than the context in qi4j. As my understanding, qi4j assume a object can partipate as different roles in different "context" (or collaboration). So, a composite can have different interface (mixin), glued in the runtime. I think in qi4j, context is the context within one application, but different scenario/collaboration (correct me if I am wrong, sorry in advance). The bounded context in Eric's book or Greg's talk, is larger. They mean different system, or big portion of a system which forms its own physical boundary (some service gateway). So, their context might require the domain model to be totally structured in different way. Inter-relationship between entities or entities themself can be different. I don't know if this is possible in qi4j. Let the domain model being adapted to different "large scale context" which requires the structure being viewed differently. Or we should not try to use one model to solve all the problem, like Eric pointed out: http://www.oredev.org/topmenu/video/ddd/ericevans.4.5a2d30d411ee6ffd28880002256.html . 2009/2/7 Niclas Hedhman <[email protected]> > 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 >
_______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
