Re: Responsibilities of ApplicationServices versus DomainServices

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]<javascript:_e({}, 'cvml', '[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.