This topic looks like BIG ENTERPRISE pattern for BIG and distributed systems.
But on the other hand it comes with nice idea that Command and Query are different and that gives a lot of flexibility in system design for the price of increased complexity, as usual.
So you take regular sync operation (pictures are from Martin Fowler and Udi Dahan blogs):
And you say that "Command Model" (usually more complex) and "Query Model" (usually basic select * from few joins ) could have different implementations:
And then you continue: "Query Model" becomes "Cache" and "Command Model" becomes "Event Sourcing" storage.
And you continue even more:
- start to treat UI as a "Task based UI flow"
- and "Commands" are stored in the DB (pretty much write-only DB) so you have "free" History
- and you may play "Commands" back and force and you practically don't need transaction logs.
- and you have many "Caches" designed for specific UI layouts
- and so on...
So "current" state of the Model is kind of blurry now and may require Rules Engine or some implementation of "Snap shoot" (this can be done during Command execution).
Martin Fowler gives good definition for pattern: http://martinfowler.com/bliki/CQRS.html
Udi Dahan talks about details: http://www.udidahan.com/2009/12/09/clarified-cqrs/
Some links and discussion/video from Chicago ALT.NET: http://chicagoalt.net/event/January2010Meeting-JdnpresentsCQRSinroughlyanhourorso
No comments:
Post a Comment