Re: Responsibilities of ApplicationServices versus DomainServices

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