On Tue, Jul 28, 2009 at 14:46, Niclas Hedhman<[email protected]> wrote: > On Tue, Jul 28, 2009 at 2:32 PM, Rickard Öberg<[email protected]> wrote: > >> Like Edward said, this needs to be related to the domain, rather than the >> service, isn't it? How to do that I'm not really sure though.. > > Ok, good point. Ideas are welcome, but I also think the current > approach will stay. > > Possible solutions; > a. Service for management of named queries. > b. Meta-info on modules/layers. > c. Named Queries stored as entities and retrieved. > d. ??
OSGi config admin like service? >> I have begun to realize that a major flaw in the general thinking about the >> Query API is that, along the thinking of the CommandQuery separation >> discussion on the DDD list, there is not generally a relation between the >> domain model and queries. If there is, that's a coincidence more than >> anything else. The reason is that the queries support the clients view and >> the operations to be performed, which is not necessarily related to how the >> domain model is structured. I have this case myself now, where the queries >> to support the client are sort of different from how the domain model is >> constructed. The client has "views" of the domain model, rather than the >> domain model. In this case there is meaning to "use the domain model" to >> construct the query where-expression. > > Ok, it seems like an extension of having the "client context" being > 'implemented' by the domain model, that we kind of are getting to at > that level. > > Perhaps a brain-storm session is in order one of these days, since > this touches not only on Named Queries but also on regular queries. Darn. Would love to be able to join this discussion. Regards, Edward Yakop _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
