Re: CQRS, Event-Sourcing and Web-Applications
"Rikard Pavelic [email protected] [domaindrivendesign]" <[email protected]> Tue, 7 Jul 2015 18:58:45 +0200
| Newsgroups | gmane.comp.programming.domain-driven-design |
|---|---|
| Message-ID | <CAMbgDOy6s=tpTS1=wesC6w1ko1C1Tz2DD1JWxphJ8f9Rxg4DPA@mail.gmail.com> |
That sounds like incorrect description of a domain event. Maybe you think events are transient messages? DE should represent a valuable business information at a specific point in time. As such its more valuable than an entity which should be reconstructable from existing events. Regards, Rikard On Jul 7, 2015 6:42 PM, "Remy Fannader [email protected] [domaindrivendesign]" <[email protected]> wrote: > > > 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 >> >> >> > >