Hi, Greg also mentioned qi4j in his interview. To some extent, qi4j is going down same path with his idea. To me, they all sounds like the form is domain model can be different tailored to different usage. In his application, read operation view the data differently with the write operation. As domain intensive logic is around write operation, so he call the data model to support write operation domain model. But essentially both data model are referencing same thing. He also mentioned nearly all real world reporting need different model than transaction processing model.
For qi4j, we are splitting the data storage and index, and require queryable column to be indexed (am I wrong? not sure). So this is like the model for query is a subset of domain model. If go further, we can introduce different possibly denormalized model for index/query. So, we already see at least four models: model for transaction processing, model to support query in transaction processing, model to support view, model to support reporting. Client/Server is another area might introduce more models. client very often do not need all data together, sometimes just a small portion. To do networking efficiently, people introduced DTO, which to me is another form of domain model. For concrete scenario, like in Greg's example, multiple bounded contexts can exists, they all share more or less same data, but view them differently. 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. 2009/2/7 Edward Yakop <[email protected]> > On Sat, Feb 7, 2009 at 13:28, Rickard Öberg <[email protected]> > wrote: > > Yeah, this interview is one of the reasons I'm really not sure how to do > > the client/server communication, and also how to expose state. He > > suggests that the domain is *write-only*, and I sort of gets his > > argument but it at the same time seems a little inconvenient. I still, > > to this date, has not seen a good solution for where and how to expose > > the domain data to the client, although I think I've seen a thousand > > discussions on DTO's. The question of "how" is very rarely resolved in > > these discussions, so I think it's something that needs more thinking. > > I just watched this. It's very interesting, although it raises more > question :) > Perhaps, we should ask Greg directly about this? > > Regards, > Edward Yakop > > _______________________________________________ > 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
