CQRS, Event-Sourcing and Web-Applications
"Rénald VENANT-VALERY [email protected] [domaindrivendesign]" <[email protected]> Tue, 7 Jul 2015 10:49:36 +0200
| Newsgroups | gmane.comp.programming.domain-driven-design |
|---|---|
| Message-ID | <CAAwYdwi8AD+r0apoUmyOGPCruESayH-VsLw3RBJoc+Z3DFZSjg@mail.gmail.com> |
Hello, As I am reading some CQRS resources, there is a recurrent point I do not catch. For instance, let's say a client emits a command. This command is integrated by the domain, so it can refresh its domain model (DM). On the other hand, the command is persisted in an Event-Store. That is the most common scenario. 1) When we say the DM is refreshed, I suppose data is persisted in the underlying database (if any). Am I right ? Otherwise, we would deal with a memory-transient model, which I suppose, would not be a good thing ? (state is not supposed to remain in memory on server side outside a client request). 2) If data is persisted, I suppose the read-model that relies on it is automatically updated, as each client that requests it generates a new state in the application (in case of a Web-Application or a RESTful architecture) ? 3) If the command is persisted, does that mean we deal with Event-Sourcing (by construct when we use CQRS) ? Does Event-Sourcing invalidate the database update process ? (as if state is reconstructed from the Event-Store, maintaining the database seems useless) ? *Does CQRS only apply to multi-databases systems (when data is propagated on separate databases), and, if it deals with memory-transient models, does that fit well with Web-Applications or RESTful services ?* Thanks, Rénald