Re: Responsibilities of ApplicationServices versus DomainServices

Just thought that I'd mention that in version 4 of NServiceBus we're supporting this form of raising domain events in-process.

It looks like this:

Bus.InMemory.Raise<ClientBecamePreferred>(m =>
                    {
                        m.ClientId = message.ClientId;
                    });

Thanks,

Udi


--- In [email protected], Wim van Gool <vangool.w@...> wrote:
>
> Greg, thanks for explaining. Just to be clear, when I talk about
> 'publishing domain events' here I don't necessarily mean publishing them on
> some external message bus like NServiceBus/MassTransit/Whatever, but just
> the 'internal message bus' aka DomainEventBus - I guess what you call
> 'producing domain events' here. But I think you gave me a valuable pointer
> in that DomainEvents are probably best managed by the aggregates themselves
> and to be published just-in-time instead of letting application-services
> handle this for certain cases...
> 
> 
> 
> On Mon, May 27, 2013 at 2:24 PM, Greg Young <gregoryyoung1@...> wrote:
> 
> > **
> >
> >
> > So the domain produces events (as in event sourced).
> >
> > You may or may not save a read model synchronously (say mongodb though
> > synchronous they're is funny).
> >
> > The events are then published.
> >
> > A whole host of issues come up if you try any other way (though the others
> > seem logical and some actually recommend them). This only applies if you
> > are raising events btw.
> >
> > Greg
> >
> >
> > On Monday, May 27, 2013, Wim van Gool wrote:
> >
> >> **
> >>
> >>
> >> Do you mean that it's *always* a good idea to implement your Aggregates
> >> such that they keep track of their own events like in an event-sourced
> >> system, but just let the repositories differ in implementation based on the
> >> choice of event-sourced or state-based systems and publish the events from
> >> there?
> >>
> >>
> >> On Mon, May 27, 2013 at 2:03 PM, Greg Young <gregoryyoung1@...>wrote:
> >>
> >>> **
> >>>
> >>>
> >>> Publish the event from the domain (domain=event only). Transactionally
> >>> save and publish event then. There are a ton of reasons for doing it this
> >>> way.
> >>>
> >>>
> >>> On Monday, May 27, 2013, Wim van Gool wrote:
> >>>
> >>>> **
> >>>>
> >>>>
> >>>> Greg, I immediately assume you're right, but what about non-event
> >>>> sourced state-based storage where you want to work with domain-events but
> >>>> still have an ORM or simple key/value aggregate-store in place?
> >>>>
> >>>>
> >>>> On Mon, May 27, 2013 at 1:47 PM, Greg Young <gregoryyoung1@...>wrote:
> >>>>
> >>>>> **
> >>>>>
> >>>>>
> >>>>> In most systems that are event sourced saving the events equates to
> >>>>> publishing. You rarely if ever want to raise events as you discuss it's a
> >>>>> ton of hidden complexity.
> >>>>>
> >>>>>
> >>>>> On Monday, May 27, 2013, Wim van Gool wrote:
> >>>>>
> >>>>>> **
> >>>>>>
> >>>>>>
> >>>>>> Jorg, I think that's quite typical and I let ApplicationServices use
> >>>>>> the repositories directly for adding and deleting aggregates too - but this
> >>>>>> means that the Application Service is also responsible for raising the
> >>>>>> Aggregate-X-Added-Events and Aggregate-X-Removed-Events, which I think is
> >>>>>> OK, but I can imagine some people feel this is a domain-concerns (raising
> >>>>>> Domain Events, that is).
> >>>>>>
> >>>>>>
> >>>>>> On Mon, May 27, 2013 at 1:05 PM, Jorg Heymans <jorg.heymans@...
> >>>>>> > wrote:
> >>>>>>
> >>>>>>> **
> >>>>>>>
> >>>>>>>
> >>>>>>> *Remaining questions*:
> >>>>>>>
> >>>>>>>> - Which service would you use to implement adding/removing
> >>>>>>>> aggregates and raise the appropriate DomainEvent?
> >>>>>>>>
> >>>>>>>
> >>>>>>> In our case applicationService.removeAggregate(id) delegates to
> >>>>>>> aggregateRepository.remove(id), why would you need a service in between ?
> >>>>>>>
> >>>>>>> Jorg
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>> --
> >>>>> Le doute n'est pas une condition agréable, mais la certitude est
> >>>>> absurde.
> >>>>>
> >>>>>
> >>>>
> >>>
> >>> --
> >>> Le doute n'est pas une condition agréable, mais la certitude est absurde.
> >>>
> >>>
> >>
> >
> > --
> > Le doute n'est pas une condition agréable, mais la certitude est absurde.
> >
> >  
> >
>



------------------------------------