CQRS - The query side

Question

A lot of the blogsphere articles related to CQRS (command query repsonsibility) seperation seem to imply that all screens/viewmodels are flat. e.g. Name, Age, Location Of Birth

Answer 1

Yeah, there's a confusion that arises. Here's how it happens: First, in order to really help new people understand what CQRS is all about, and to really drive home how it differs from the typical layered architecture, people say things like, "Your view models can be completely flat", and "You should have one table per view model in your Query database."

But that is really just meant to drive the point home ... it is not true that you must have only one table per view model (though in most cases you probably should). What those statements are trying to say is this: "You've got to shake yourself free of some rules that you've followed for so long about normalization. With the CQRS architecture, you have the opportunity to make database tables in your Query channel that are completely shaped according to the needs of your view and nothing else. Make sure you take full advantage of that. Don't go halfway by normalizing these tables just because it is what you're accustomed do. Instead, go ahead and do things that used to be considered unthinkable, such as making one database table per view model, or making your view model tables completely flat."

There are still cases such as yours where the schema that would best serve your needs would have multiple tables. You might even (God forbid) do a Join or two. That's fine, as long as you really have designed the database tables to serve your view, and not vice versa. But be careful, it is easy to slip down the slope of normalization and sharing data between many views in the Query database. Don't go there ... there's simply no reason and it incurs more cost than benefit. The main goal is this: Your View logic should be dead, dead simple. You want the intelligent rules living on the Command side of the house, and a little bit in the Subscribers that populate the data in the Query channel. So the code that reads from the Query database and shows data on a screen should be dead simple (almost as simple as a "passive view").

Update: As further backing for the statement that it is not "forbidden" to do some joins as long as you have designed the database shape to best serve the task you're achieving, consider OLAP. The star schema is a perfect example of a database schema designed to support reads, that fits perfectly in the Query side of CQRS, and that does involve joins. The joins are kept simple, and they are in place to further enhance the goals of the Read tasks performed against the database.