Re: Domain Event Objects vs Standard Events
"Marco Paul [email protected] [domaindrivendesign]" <[email protected]> Wed, 27 May 2015 17:03:18 -0400
| Newsgroups | gmane.comp.programming.domain-driven-design |
|---|---|
| Message-ID | <[email protected]> |
I am more so interested in the implementation. Also let's assume not talking about an event sources model as I understand the mechanics around the first class domain events approach. Sent from my iPhone > On May 27, 2015, at 4:48 PM, Remy Fannader [email protected] [domaindrivendesign] <[email protected]> wrote: > > The critical distinction is between actual (aka external) and symbolic (aka internal) events. The former are associated with changes in the state of actual objects or activities, including agents’ expectations. The latter are associated with changes in symbolic representations of objects or activities. Their mapping depends on synchronization requirements. > https://caminao.wordpress.com/how-to-implement-symbolic-representations/patterns/functional-patterns/event-patterns/ > Remy. > > > >> On 27 May 2015 at 21:10, [email protected] [domaindrivendesign] <[email protected]> wrote: >> >> What's everyone opinion on using (assuming .NET) standard custom events as opposed to the traditional DDD way (static domain publisher class)? >> >> >> >> sure you are more tightly coupled, but I would think in most instances the client of the domain model is the application layer and this type of coupling is not very harmful. The application layer has enough knowledge for the given use case on how to dispatch the events, in-process, on the bus, in-line, etc. >> >> >> >> I don't see many people talking about this approach and I was wondering why? here is some pseudo-code i've been toying around with. >> >> >> >> Deferred deferred = new Deferred(); >> >> >> >> Consignee consignee = new Consignee(); >> >> >> >> consignee.Created += >> >> (s, e) => deferred.Enlist(() => Bus.Publish(e)); >> >> >> >> repository.Add(consignee); >> >> >> >> deferred.Continue(); >> > >