@Ayende, Can't wait! @Corey, Wow. Udi has an awesome presentation. This cleared up many of questions about CQRS and how scalability is possible. I was shocked by the ATM example. I figure most are:)
Udi doesn't mention any specific implementations in his presentation. When referring to a Persistent View Model my first thought was RDBMS tables since the schema of this portion of the system is flat it works. I guess a document DB could work here as well, but the view model isn't an object by definition, so why build it that way? then again if you have an order entry screen with order header information and lines this would be 2 tables for the presentation view, (header for referencing number, date, payment method, etc and order lines to edit). So maybe a document DB can provide value. This would change how my service bus and web interact. everything becomes a one way message. the web would send a command to the service and continues accessing the persistent view model. the service would process the command against the domain. upon success the service would send another command to the persistent view model. the persistent view model receives the command and updates itself. Depending upon how stale the persistent view model can be. the options for updating the view model are greater. single row commands, or a single command for batched ETL. However all this still depends on the client. If the client is still dependent on paper, wants tabbed screens or believes real time data is required this model does not work. On Mar 15, 5:54 pm, Corey Kaylor <[email protected]> wrote: > Even though I should wait for your draft before discussing. After spending > some time with Udi's Command Query responsibility segregation > here<http://skillsmatter.com/podcast/open-source-dot-net/udi-dahan-command...>. > I couldn't help but think that document databases were a perfect fit for the > view model persistent storage i.e. the query. Continuing to use a relational > model for asynchronous commands sent as messages on a bus, but that the > relational database would be the "truth", and everything should be derivable > and persisted from it in a document database specific for the screens that > use the information. Then the choice becomes how often should the document > database be synchronized. This makes for a good argument for using Rhino-ETL > for the occasional synchronization, and event messages sent via Notify for > more real-time synchronization. Am I way off base? -- You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rhino-tools-dev?hl=en.
