Hello Pål.

I find your figure very informative, and the topic is very relevant. The most interesting feature to me is the way it suggest how to build modern smart clients on top using known technologies like WCF. Personally i have given some thought to designs where the smart client also responds to events from this and other systems. For instance updated-events and other relevant information. Is this something you have done or thought about ? If so I would very much like a follow up on this topic.

Concerning the 2 databases, the way it is formulated, one can almost think that you just denormalize and duplicate all the data?

In my own thoughts about this topic i think of the main database as the "master" database, in which the exact state of he system is stored.

While the databse you describe as "optimised for reading", i tend to think of as almost a parallell system, built for user representation of the same data. This could well be a smart client, or a BI reporting solution.

But this would not require that all information is stored in this system from the beginning ? It would be tailored to specific needs. Building on these thoughts it is also possible to envision several such query systems for different kinds of clients. I.e. a BI reporting solution which might use a star schema ?

All in all a very informative figure.

Hi Pål
Interesting articles. I haven't used that kind of architecture, so my question are very teoritical and your practical experience is very valuable
Did you push the query optimization to have tables mapping directly to your viewmodels? like suggested in Udi's post http://www.udidahan.com/2009/12/09/clarified-cqrs/ in the "Queries" paragraph.
Regarding your CommandFacade, what do you mean by "holds ORM state through calls"? Don't you use som kind of Session-per-request.
And a last question, on your diagram you are sending messages to your denormalizer. Do you used a publish/suscribe or do you send message explicitly to the denormalizer (kind of commanding the denormalizer)? In case of publish/suscribe did you managed to use the same events that you publish (on the left of the diagram)

@Anders
>Is this something you have done or thought about ? If so I would very much like a follow up on this topic.

I haven't tried to build a smart client that responds to events, so I haven't any information to share on that topic. Sorry :-( But it's an interesting thought. How do the smart client pick up these events? From a bus or queue?

>...you just denormalize and duplicate all the data?

I see that this can be a bit misleading. If you look at the figure in this post, I have added a pipeline from the application service and down to the de-normalizer. All the changes in the domain model is sent though this message-pipeline (to a queue/bus), after a writing to the write database. Errors triggered by writing to the write database can stop the process. At the moment we are just creating views in the write database that is used in the read database, we haven't plugged in the bus yet.

We are duplicating data between the read database(s) at the moment, but we will add filters in the future so only data that are relevant to the view model will be synchronized.

>This could well be a smart client, or a BI reporting solution.

I look at the read-side as a database for reporting. Everything in the GUI is a report; nothing is written back to the read database. I look at the BI reporting solution as a different context (I have planned to blog about this later). We haven't built this yet, but everything will be plugged in to a service bus in the future. Then the CQRS architecture will just be a small part of the system. We don't want to put everything into "on big ball of mud". The BI solution can then "pick" data for the service bus and into a staging database and eventually into a star schema.

@Dom
>Did you push the query optimization to have tables mapping directly to your viewmodels?

Yes, this is the plan. At the moment we are using database views to simulate the tables tailored against the view model in the GUI.

>Regarding your CommandFacade, what do you mean by "holds ORM state through calls"? Don't you use som kind of Session-per-request.

Yes, I guess this information is unnecessary

>And a last question, on your diagram you are sending messages to your denormalizer.

Yes, we are planning on doing this. At the moment we have just done some profe-of-concept. All events will eventually end up in a service bus through an autonomics component.

@Pål
Yes what I was thinking about for the client would be a channel on the bus which also reaches the client. Or if there are any other suitable methods of notifying the client, without the client making requests to be updated.

thanks for this usefull informations..
now i find something that i want to know..