The “denormalizer” is a component responsible for mapping data from the domain model to a denormalized table structure at the query side (an over can be found here). Usually the denormalizer component runs as a windows service at the server hosting the query side. Its only responsibility is to move data from the command side to the query side, and function as a router for messages from the write side. You might not want the same data on all the read servers.
Database tables matching view models
On the query side, all the tables match a view model in the GUI. Yes, this means you will end up with some duplicated data in the database tables, but that’s ok. Hard disk space is cheap.
Let’s look on how the denormalizer fits into the architecture.
When the domain model have done its stuff, an event is raised and a message is sent through a “pipeline” to the denormalizer on the query side. The “pipeline” can be a queue or something else that is fit to move the message in a safe way. I have used NServicebus with a lot of success, but there are other ESBs or other ways to do this.
Easy programming model
When the denormalizer receives the message, it spreads the data into the tables that needs to be updated . The tables have a one-to-one relationship with the view models. A GUI view can have multiple view models. What this gives you is a very easy programming model on the query side. All you have to think about concerning the denormalizer, is to insert/update the data to the correct tables. From the client, you look at the data as reporting data; meaning you can’t update or insert data on the query side.
All though I’m referring to a relational database at the query side in this post, it doesn’t have to be a relational database. You can use a non relational database if you want to. I would recommend MongoDB over a object database like DB4o, but that’s just my taste at the moment. You can even build your own key-value store because in most GUI views you will just fetch data based on an id.
To sum it up; the denormalizer routs the messages from the command side in to the correct tables on the query side.