I've been working with CQRS for almost a year. Ever since I first heard about it, I was immediately convinced that it had the ability to vastly simplify a lot of unnecessary development overhead. In this particular post, I will not be discussing event sourcing which is often mingled with CQRS. Instead, I will be focusing on the query side of the equation.
Please note that the ideas contained herein are merely conjectures of what might be rather than any kind of working, concrete implementation. I've thought my way through some aspects and ramifications of implementing what I mention below but new insights will undoubtedly merit additional consideration. Furthermore the solutions outlined below need not be considered mutually exclusive with more traditional ways of doing things. There is definitely room to implement portions of what I mention for specific views while doing things in the traditional way in other views.
ViewModel Tables
Several weeks ago I blogged about having one table per view. Since that time Udi Dahan has mentioned it as well, although independently of my post. Querying view model tables directly, which comes as a positive consequence of implementing CQRS, enables us to avoid having numerous mapping layers between the database and the view. Further, it allows us to avoid projecting off of our domain model and keeps the domain model focused solely on behavior. Lastly, it allows us to scale the read database independently of the write database.
Content Delivery Networks
Think for a moment about the pure static resources that are handled on a given website. They just sit there with the exact same content for each request. These are the exact kinds of resources for which we could leverage a content-delivery network. In other words, we could push these static elements to a CDN and have the CDN deliver them for us thus offloading traffic from our servers and freeing our web tier to perform more interesting tasks—such as processing update-type commands. Not only does this offload work from our web tier, but the user has a better and faster browsing experience.
HTML + JSON
In ASP.NET as well as other server-based page-rendering technologies we typically have the request come all the way to our server and then we render some HTML but with a few modifications depending upon the user. Could there be a way to somehow render static layout HTML but render the parts that vary separately? Why not have the pages render identical static HTML regardless of user and then, on a separate request, render the user-specific content and then stitch the two together using JavaScript?
Let me say that another way. Our MVC view or our ASP.NET "Page" could render pure HTML with absolutely no server-side markup. Inside of that HTML we would have the URL of an embedded resource: . The request to this embedded resource would call our MVC controller and then render JSON data with user-specific information for the currently logged-in user for that view. We could then use a client-side JavaScript templating engine such as jTemplates to combine the JSON with the static HTML.
Static HTML Views + CDNs
The above has some interesting ramifications. Why couldn't we just put the static HTML for each view into an HTML file and push those HTML files to a CDN? The static HTML files would have