Re: Re: Responsibilities of ApplicationServices versus DomainServices

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 <[email protected]
> 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.
> > >
> > >
> > >
> >
>
>  
>