Re: Responsibilities of ApplicationServices versus DomainServices

Yes - I recommend raising domain events "on the spot".

If something else wants to record them for persistence purposes as a part of a larger unit of work, that's fine - as a separate concern.

I wont try to put words in Greg's mouth.

-- Udi


--- In [email protected], Wim van Gool <vangool.w@...> wrote:
>
> Udi, Greg, since you've both posted here, I'm curious if both of you have
> same the view on how and when domain events should be raised (in memory,
> that is). @Udi: by reading your blog and code samples (which I adopted many
> best practices from), I felt that domain events are to be raised on the
> spot; that is, immediately after the change in the system has occurred (but
> before persistence), like:
> 
> public sealed class FormulaOneCar : IAggregateRoot
> {
>     ...
> 
>     public void ChangeTires(TireSet newTires)
>     {
>         _tires = newTires;
> 
>         DomainEvents.Raise(new FormulaOneCarChangedTiresEvent(_id,
> newTires));
>         // or Bus.InMemory.Raise :)
>     }
> }
> 
> Whereas the other approach is to let the aggregates store all their domain
> events and publish them on commit, even if you are not doing event sourcing
> (assuming that is how you meant it, Greg, but please correct me if I'm
> wrong).
> 
> What are the exact pro's and con's of both (other than that one lends
> itself much better if you're considering to use event sourcing)?
> 
> 
> On Tue, May 28, 2013 at 5:03 PM, udidahan7 <thesoftwaresimplist@...
> > wrote:
> 
> > **
> >
> >
> > 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.
> > > >
> > > >
> > > >
> > >
> >
> >  
> >
>




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