Moved things around in the application and presentation areas

Instead of having Presentation query RavenDB for read models I am going to go with sending queries via nservicebus to application layer who will then respond with one or more messages containing the results of the query.

There are 2 articles I've read about this approach -

This one says don't do it
http://andreasohlund.net/2010/04/22/messaging-shouldnt-be-used-for-queries/

This one says go for it
http://www.udidahan.com/2007/11/10/asynchronous-high-performance-login-for-web-farms/

I was originally planning on doing this but the first article made me rethink.  However the second article is written by the writer of NServiceBus sooooo

Anyway, the idea is that when ServiceStack needs to query, I send a query command to the application layer.  The application layer then REPLIES with one or many messages which are the result of the query.  ServiceStack will then cache those results in redis for future queries.

Why separate presentation from the DB?  The problem is the DB is created by a worker application service.  The application service doesnt HAVE to write to RavenDB, its just choosing to.  In the future maybe we'll have an application service for BI or data mining.  How would the presentation layer
query that data?  It would have to setup a connection to the BI DB... and so on and so on.  In any scale out scenario, the DB is always the bottleneck - by separating presentation from application I am attempting to eliminate this.  Since if I spin up 10 or 20 presentation layers they would ALL have to
connect to each DB used...

Instead, with the query/reply pattern I can query the application layer for some data I want, and I don't care at all where it comes from.  And redis cache reduces the overhead of using NServiceBus as my dbconnector.

Note we could also deploy an application service on the presentation server to feed redis to further reduce or eliminate cache misses.

Fun fun