A few things. First, while it is common that a projection is interested in only events from a type of producer (aggregate/actor/etc) it's also quite common they need to listen from many types.
"I believe that it is quite important to have these API case classes standardized as much as is reasonably possible. Because that allows me to use another persistent store for testing (like leveldb / inmem) while in production it makes use of kafka or some other store. I'd prefer to have the akka-persistence layer in between, allowing me to choose the setup according to the situation. (instead of tying directly to a kafka topic / eventstore stream)" Wouldn't this only apply to integration testing? For all other testing wouldn't you just output events through whatever stream interface you were using? For integration purposes I know event store supports a memory only model and I would imagine Kafka does as well. Cheers, Greg On Thursday, August 28, 2014, Olger Warnier <[email protected]> wrote: > Hi Roland, > > great conclusion, with everything said till now in mind. I'd like to > mention a view points and like to hear if this matches your thoughts: > > The QueryByTypeDeterministic(type, from, to) mentioned by Martin matches > with the way I've been using DDD+CQRS for last 2 years. > Meaning that the type is actually the type of the PersistentActor. (not of > an event) > By streaming all events of a certain PersistentActor type, it's possible > to create current state (for instance in a RDBMS or Graph database) that is > used by the application. The application Queries these stores (RDBMS/Graph) > and will not use the event stream or journal in a direct way. (so the real > performance requirements are somewhere else) > > I believe that it is quite important to have these API case classes > standardized as much as is reasonably possible. Because that allows me to > use another persistent store for testing (like leveldb / inmem) while in > production it makes use of kafka or some other store. > I'd prefer to have the akka-persistence layer in between, allowing me to > choose the setup according to the situation. (instead of tying directly to > a kafka topic / eventstore stream) > > One remark about the QuerySuperscalableTopic (or kafkatopic) > I assume the 'name' parameter has to be created in the store in question > (just like an index for an RDBMS). > This feels like moving part of the responsibility of the way your CQRS > framework works towards an external component (if this 'index' is not > created, the thing does not work). When you look at the initial 'tag' > proposal, you had to code a tag (write side) that could be used on the read > side. > In this construction you will be able to test the code setup without being > dependent on a specific store setup. > > > Kind regards, > > Olger > > >> -- Studying for the Turing test -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
