Re: CQRS, Event-Sourcing and Web-Applications

Persisted events and persistent entities should not be confused: the former
are plain value objects in buffers whose processing is governed by
synchronization constraints, the latter are meant to be continuously and
consistently mapped to their actual business counterparts.

On 7 July 2015 at 10:49, Rénald VENANT-VALERY [email protected]
[domaindrivendesign] <[email protected]> wrote:

>
>
> 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
>
>
>  
>