CQRS Triangle

I saw Gabriel Schenker of Topaz Technologies present on CQRS (Command Query Responsibility Segregation), a term coined by Greg Young, at ADNUG on Monday.

• In Gabriel's approach there is a triangle. The client hands commands to the domain which hands events to the read model. The client also hands queries to the read model for data and from the read model gets back DTOs.
• Commands handed to the domain can spawn events which are pushed to the read model, or they may simply fail. The client will get back an Ack/Nack (pass or fail) for each command handed to the domain. An Ack/Nack is not just a boolean value as the Nack carries with it an explanation of what went wrong. Imagine a form being submitted and a success or failure message then bubbling back up to the view.
• The scheduling of a new task, such as placing an order an amazon.com, is an example of a typical command. Eventual consistency will come from the triangle!
  
  0.1% of the time when amazon.com turns out to be out of copies of "How to Win Friends and Influence People" upon attempted event fulfillment even though copies existed upon ordering, the asynchronous inconsistency is addressed with an apology and "store credit." This approach comes with a "it is OK to occasionally fail" philosophy.
• An event spool should hang off of the domain, saving the events somehow. (This sort of logging is called "Event Sourcing.") Gabriel's approach did eventhing with flat files. One should be able to recreate everything in the read model (again, flat files in Gabriel's implementation) from rerunning events in the appropriate order.
• The events in the event spool should not be editable. They should go in in a sequence so that they may be rerun in the appropriate sequence.
• What should we do if an event is messed up and we cannot edit it? We should write a correction to compensate for the error instead of trying to pretend the error didn't exist (via redacting) in the same way accountants write "journal corrections."
• Aggregrates (in the domain) process POCO commands pushed from the client. If things go right, an aggregrate will produce one event per command.